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By  Memorandum  dated  August  17 ,  1977,  the  Deputy  Assistant  Secre¬ 
tary  of  Defense  (Supply,  Maintenance  and  Services)  established 
a  Department  of  Defense  Study  to  conduct  a  comprehensive  review 
and  analysis  of  the  supply  support  request  (SSR)  systems  for 
generating,  transmitting,  processing  and  controlling  SSRs  in 
order  to  develop  systems  Improvements  to  promote  effective  supply 
support  of  DoD  equipments. 

The  Study  included  a  review  of  SSR  policy  and  procedures,  the 
design  of  automated  systems  to  implement  the  procedures  and  an 
operational  implementation  review  of  the  effectiveness  of  SSR 
systems  design. 


This  Report  documents  the  study  approach  and  methodology  used  in 
the  pursuit  of  the  study  and  presents  observations,  analyses, 
findings,  conclusions  and  recommendations  with  supporting  re¬ 
search  and  rationale. 
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CHAPTER  I 


! 

INTRODUCTION 


A.  THE  STUDY  ASSIGNMENT 
1 .  Background 

In  August  1972,  the  Deputy  Assistant  Secretary  of  Defense 
established  a  study  of  Item  Logistics  Management  Data  (ILMD)  In 
the  Department  of  Defense  (DoD) .  The  term  ILMD  encompassed  that 
data  related  to  requests  for  supply  support,  cataloging  data  for 
Item  Identification,  catalog  management  data,  and  data  distrib¬ 
uted  in  change  notice  procedures.  The  following  functional  areas 
were  reviewed: 

:  Provisioning  procedures  and  schedules 

:  Provisioning  technical  documentation 

:  Item  screening  procedures 

:  Supply  support  requests 

:  Item  management  coding  and  classification 

:  Cataloging 

The  ILMD  Study  (Appendix  D,  Reference  1)  concluded  that 
there  were  multiple  regulatory  procedures,  formats  and  data  ele¬ 
ments  that  had  an  adverse  effect  upon  Inventory  Control  Point 
(ICP)  supply  support  operations,  and  recommended  that  these  pro¬ 
cedures  (Appendix  D,  References  2  to  8)  be  combined  into  one  DoD 
manual.  These  procedures  were  revised  and  consolidated,  and  are 
contained  in  DoD  4140. 26M  (Appendix  D,  Reference  9),  which  was 
coordinated  and  approved  for  implementation  by  the  Military  Ser¬ 
vices,  Defense  and  Civil  Agencies  (hereinafter  referred  to  as 
Components)  through  the  DoD  Special  Projects  Group  (SPG)  for 
provisioning  with  a  scheduled  implementation  date  of  1  May  1978. 

The  SPG  is  composed  of  members  from  the  Military  Ser¬ 
vices,  Defense  and  Civil  Agencies,  and  a  chairman  from  the  Assis¬ 
tant  Secretary  of  Defense  (Manpower,  Reserve  Affairs  and  Logis¬ 
tics)  (ASD(MRAAL) )  .  The  group  meets  on  an  ad  hoc  basis  upon  the 
request  of  the  chairman.  Agenda  are  usually  prepared  in  advance 
of  the  meetings  and  outline  material  to  be  discussed  during  the 
meetings.  Topics  related  to  provisioning  are  considered.  Prob¬ 
lems  being  experienced  in  provisioning  or  related  areas  are 


discussed  and  potential  solutions  are  developed*  The  SPG  is  the 
primary  forum  for  discussion,  development,  and  coordination  of 
policy,  procedures  and  specifications  governing  the  provisioning 
of  end  items  of  equipment  in  the  Department  of  Defense. 

Subsequent  to  the  coordination  of  the  new  procedures, 
and  prior  to  implementation,  potential  problem  areas  in  the  pro¬ 
cessing  of  supply  support  requests  (SSRs)  which  could  have  an 
adverse  effect  upon  supply  support  of  new  systems  surfaced. 
During  meetings  of  the  SPG,  it  was  alleged  that  SSRs  were  not 
being  processed  in  a  timely  manner  necessary  to  ensure  effective 
and  efficient  supply  support  of  end  items  of  materiel. 

2 .  Problems 

Problems  were  reported  in  the  areas  of  SSR  transmission 
times  and  excessive  reject  rates  which  delay  vital  supply  sup¬ 
port.  Also,  it  was  felt  that  there  was  a  lack  of  effective 
management  control  systems  to  monitor  and  control  the  overall 
SSR  process.  Problems  related  to  SSRs  identified  by  the  SPG 
include : 

:  Extended  transmission  times 

:  Delinquent  SSRs 

:  Excessive  number  of  rejects 

:  Inadequate  controls 

:  Deficient  management  reports 


These  types  of  problems  are  related  to  the  systems  devel¬ 
oped  by  SSR  submitters  and  receivers  to  implement  the  standard 
DoD  procedures,  formats  and  data  elements.  It  was  thought  that 
publication  of  the  new  procedures  alone  would  not  necessarily 
correct  the  types  of  problems  being  experienced.  These  problems 
were  considered  so  significant  that  the  SPG  recommended  that  a 
study  be  conducted  by  an  independent  organization  to  ensure  an 
impartial  review  and  analysis  of  the  various  SSR  systems. 

3.  Tasking 


By  memorandum  dated  August  17,  1977,  the  Deputy  Assis¬ 
tant  Secretary  of  Defense  (Supply,  Maintenance  and  Services) 
established  a  Department  of  Defense  Study  to  conduct  a  compre¬ 
hensive  review  and  analysis  of  the  supply  support  request  sys¬ 
tems.  Appendix  A  contains  a  copy  of  this  memorandum  including  a 
statement  of  the  study  requirements. 
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The  Director  for  Supply  Management  was  assigned  as  the 
primary  study  sponsor  responsible  for: 

:  Study  definition  and  scope 

:  Objectives 

:  Study  assignment  and  tasking 

:  Monitoring  study  progress 

:  Receipt,  coordination  and  implementation  of  study 

results . 

The  Defense  Logistics  Analysis  Office  (DLAO)  was  assigned 
to  conduct  the  study.  Responsibilities  of  the  study  office 
include: 

:  Determining,  requesting,  obtaining  or  supplying  re¬ 

sources  to  perform  the  study. 

:  Development  and  application  of  study  methodology  in¬ 

cluding  identifying,  collecting,  obtaining  or  developing  data / 
information  and  techniques  to  analyze  systems  and  evaluate 
alternatives  for  accomplishment  of  the  study  objectives. 


The  military  departments  and  defense  agencies  were  re¬ 
quested  to  designate  their  SPG  representatives  as  the  study  point 
of  contact  to  coordinate  study  group  requirements  for  briefings, 
information,  visits  and  service/agency  participation  in  the 
study  effort.  It  was  felt  that  this  would  facilitate  the  con¬ 
duct  of  the  study  since  the  SPG  members  are  knowledgeable  in  the 
functional  areas  under  study,  had  a  primary  interest  in  the  study 
due  to  their  participation  in  the  problem  definition  and  their 
role  in  the  recommends tion  for  the  assignment  of  the  study. 

4.  PurpioTe^-^  The  purpose  of  the  study  was  to  identify  prob¬ 
lems  associated  with  the  systems  for  generating,  transmitting, 
processing  and  controlling  SSRs  in  order  to  develop  systems  and 
procedures  improvements  to  promote  effective  and  efficient  sup¬ 
ply  support  of  DoD  equipments,  -s, 


5  .1  Objectives 

\^The  objective  of  the  study  was  to  Increase  the  effective¬ 
ness  and  efficiency  of  supply  support  through: 


Decrease  in  supply  support  request  transmission 
and  processing  times..  .  r 

s  v—  j  n...  f  0  c 


i 


Reduction  in  rejection  and 


delinquency 


rates ^  a*~ctr 


Improvements  in  systems  and  procedures  for 
generating,  transmitting,  processing  and  con¬ 
trolling  SSRs .  v 


These  objectives  are  goal  oriented  towards  the  correc¬ 
tion  of  problems  associated  with  the  SSR  system. 

6 .  Scope 

a.  Definition.  Supply  support  requests  for  the  purpose 
of  the  study  Include  all  data  or  information  required  to  request 
and  obtain  supply  support  for  end  items  whether  for  provisioning 
or  nonprovisioning  requirements.  The  definition  was  purposely 
broad  to  permit  the  study  group  freedom  to  explore  all  vehicles 
actually  being  used  to  request  and  obtain  supply  support.  The 
rationale  behind  this  is  that  if  methods  other  than  those  con¬ 
tained  in  the  SSR  manual  are  being  used,  they  should  be  evaluated 
to  determine  if  they  are  more  effective  or  efficient,  or  whether 
prescribed  procedures  are  deficient.  This  definition  is  subject 
to  refinement  during  the  course  of  the  study. 


b.  Inclusions .  The  study  involved  supply  support  for 
consumable  items  subject  to  item  management  assignment  proce¬ 
dures  in  accordance  ,with  the  Defense  Integrated  Materiel  Manage¬ 
ment  Manuals  (Appendix  D,  References  4  and  9).  Both  commodity 
and  weapons  system  ^oriented  consumable  items  are  in  this  cate¬ 
gory. 


c.  Exclusions 


Items  not  subject  to  item  management  assignment  in 
accordance  with  these  manuals  are  excluded  from  the  study.  Ex¬ 
cluded  items  are: 

:  Medical  Material 

:  Clothing  and  Textiles 

:  Subsistence 

:  Ammunition 

:  Fuels 

Review  and  analysis  of  computational  formulas  for 
the  range  and  depth  selection  of  quantities  of  items  was  also 
excluded.  Policies  and  procedures  for  the  determination  of  ini¬ 
tial  requirements  for  secondary  item  spare  and  repair  parts  con¬ 
tained  in  DoDI  4140.42  (Appendix  D,  Reference  10),  were  specif¬ 
ically  excluded  from  the  study  by  the  study  sponsor. 


However,  ee  a  natural  part  of  the  review  of  the  SSR 
processes,  the  study  group  was  chartered  to  consider  the  criteria 
and  tlalng  of  when  an  SSR  would  or  would  not  be  generated,  the 
parameters  and  conditions  governing  the  types  of  SSRs  to  be  sub- 
aitted,  and  aethodology  of  generation  and  subalsalon. 

d.  Research .  The  study  group  was  chartered  to  review 
and  analyte  the  SSR  pipeline  froa  generation  through  coapletion 
of  processing  of  SSRs.  Research  was  perforaed  on  systeas  types, 
systeas  characteristics  and  organizations  involved  in  the  study 
problem . 

(1)  Systems  Types.  A  system  may  be  comprised  of  a 
number  of  subsysteas  or  components,  which  aay  come  Into  play  at 
any  time  from  the  Initial  creation  of  an  SSR  until  Its  ultimate 
completion.  It  was  the  Intent  of  the  SSR  study  to  research  each 
of  the  different  types  involved  In  the  SSR  processes  froa  the 
beginning  to  end.  The  study  requirement  stratified  SSR  systeas 
into  five  basic  types: 

:  Generating 

:  Tr ansmittal/Communicatlon 

:  Processing 

:  Control 

:  Management 

(2)  Systems  Characteristics.  A  system  does  not 
usually  operate  independently  of  other  systeas;  therefore,  the 
study  was  also  concerned  with  other  systems  that  interfaced  with 
SSR  systems  to  the  extent  other  systems  were  considered  to  have 
a  significant  impact  on  the  SSR  system.  The  scope  of  the  re¬ 
search  dealt  with  the  basic  elements  of  a  system  such  as: 

:  Procedures 

:  Inputs/outputs/files 


:  Formats/content/data  element s /code  s/de f ini- 


t  ions 


:  Media/mode/tlmlng/techniques 

(3)  Organizations .  All  DoD  and  Federal  Components 
using  the  DoD  procedures  contained  In  the  DoD  Integrated  Materiel 
Management  Manuals  were  subject  to  the  study.  The  principal 
organizations  using  the  manuals  in  addition  to  DoD  are  the  Gen¬ 
eral  Services  Administration  (GSA)  and  Coast  Guard. 
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7 .  Assumptions 


There  was  only  one  assumption  placed  In  the  study  require¬ 
ment  by  the  study  sponsor.  The  study  requirement  stipulated  that 
there  will  be  a  single  DoD  manual  with  one  set  of  formats,  docu¬ 
ment  identifiers,  procedures  and  codes  for  the  interchange  and 
processing  of  supply  support  requests.  This  condition  was  im¬ 
posed  because  of  the  problems  caused  by  multiple  directives,  for¬ 
mats  and  codes  which  resulted  in  the  recommendation  for  a  single 
DoD  manual  for  SSRs  by  the  ILMD  study. 

It  was  not  intended  that  this  would  preclude  the  study 
group  from  establishing  additional  assumptions  associated  with 
the  approach  and  methodology  used  in  the  conduct  of  the  study. 

B.  APPROACH 


The  general  orientation  of  the  study  approach  was  influenced 
by  the  description  of  the  problems  and  objectives  in  the  study 
assignment.  The  study  group  set  out  to  develop  a  research  plan 
that  would  permit  an  analysis  of  the  problems  reported  in  con¬ 
sonance  with  an  overall  review  of  SSR  systems  to  accomplish  the 
objectives  of  the  study.  A  three-point  plan  was  developed  to 
accomplish  this  action.  The  main  thrust  of  the  study  was  to 
perform  a  complete  systems  analysis  due  to  the  nature  of  che 
problems  brought  up  by  the  SPC.  These  problems  appeared  to  be 
systems  rather  than  procedurally  or  organisationally  oriented. 

The  systems  analysis  covered  the  design,  development  and  imple¬ 
mentation  of  systems  to  implement  the  SSR  policies  and  proce¬ 
dures  contained  in  DoD  4140. 26M,  Vol  1.  The  systems  analysis 
was  supplemented  by  an  evaluation  of  the  effectiveness  of  these 
systems  coupled  with  a  problem  analysis  of  SSR  problems  reported 
from  any  source  involved  in  supply  support. 

1 .  Study  Team  Composition 

Three  basic  types  of  expertise  were  required  to  perform 
the  study  as  planned;  logistics  systems  analysts  to  provide  the 
broad  logistics  systems  knowledge  pertaining  to  SSRs  in  the 
logistic  environment,  computer  systems  analysts  to  provide  the 
capability  of  analyzing  automated  data  processing  systems  for 
SSRs  and  operations  research  analysts  to  permit  an  evaluation  of 
the  effectiveness  of  competing  systems.  The  initial  staffing  of 
the  study  team  was  developed  from  a  blend  of  a  combination  of 
these  skills  to  complement  and  balance  each  other  with  an  experi¬ 
enced  study  leader  as  director.  Staffing  of  the  immediate  study 
team  is  shown  as  follows: 
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Position 


Grade/Rank 


Study  Director 
Logistics  Systems  Analyst 
Logistics  Systems  Analyst 
Computer  Systems  Analyst 
Operations  Research  Analyst 


GS-15 

Lieutenant  Colonel 

GS-13 

GS-13 

GS-13 


However,  a  study  of  this  magnitude  could  not  be  accom¬ 
plished  without  augmentation  and  assistance  to  the  basic  study 
team.  Figure  1-1  below  provides  a  better  picture  of  the  total 
team  concept  employed  by  the  Department  of  Defense  Supply  Sup¬ 
port  Request  (DODSSR)  Study  Team. 

THE  TEAM 


Figure  1-1 


The  DODSSR  Study  Team  can  be  viewed  as  a  pyramid.  The 
basic  team  with  staffing  as  described  above  represents  the  nu¬ 
cleus  as  depicted  by  the  second  layer.  The  immediate  team  is 
supported  by  study  coordinators,  analysts  and  programmers  from 
the  headquarters,  systems  design,  operating  and  administrative 
services  levels  from  the  Military  Services,  Defense  Logistics 
Agency  (DLA)  and  the  General  Services  Administration  (GSA). 
Assistance  was  provided  to  the  DODSSR  Study  in  accomplishing  our 
headquarters  and  field  research,  the  conduct  of  our  tests  and 
completion  of  our  data  collection  and  analysis.  Participation 
commenced  with  the  SPG  members  who  coordinated  st\idy  require¬ 
ments  from  the  beginning  of  the  study  through  our  visits  to 
systems  design  and  operating  activities  and  completion  of  our 
quantitative  analysis.  The  pervasiveness  of  this  participation 
extended  throughout  the  study  and  is  considered  unprecedented. 

2 .  Study  Phases 

Originally  the  study  requirement  provided  for  a  short 
and  a  long  range  phase  of  study.  The  short  range  was  intended 
to  permit  early  ide  n  t  i  f  ic  a  t  i  on  of  those  changes  that  were  re¬ 
quired  to  be  made  to  permit  a  working  implementation  of  the 
draft  SSR  procedures  that  were  scheduled  for  implementation  on 
1  May  1970.  This  phase  would  then  provide  the  foundation  for 
the  accomplishment  of  Phase  2.  Problems  to  be  researched  and 
corrected  during  Phase  1  were  to  be  identified  by  the  SPG  and 
presented  to  the  study  group  for  resolution. 

During  the  SPG  meeting  of  6-7  October  1978  no  operational 
problems  requiring  immediate  attention  were  identified  or  pre¬ 
sented  to  the  study  group  for  research.  The  concensus  of  the 
SPG  members  was  that  the  new  system  would  have  to  be  tested, 
installed  and  some  operational  experience  gained  prior  to  iden¬ 
tifying  problems  with  either  the  procedures  or  the  systems  devel¬ 
oped  to  implement  the  procedures.  The  short  range  research  was 
then  abandoned  and  the  study  team  proceeded  to  conduct  the  study 
In  accordance  with  normal  study  procedures. 

Seven  study  phases  were  established  to  accomplish  the 
general  plan  of  study.  These  phases  were  intended  to  permit 
research  to  progress  from  the  general  to  the  specific  to  provide 
a  detailed  understanding  of  SSR  systems  and  associated  problems, 
and  consisted  of  the  following  segments: 

:  Background/docuncnt  research 

:  Headquarters  policy  level  review 

:  Systems  design  review 
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Operational  implementation  review 


:  Data  collection  and  analyses 

:  Synthesis 

:  Final  evaluation  and  report  preparation 

These  phases  were  pursued  in  the  general  chronological 
order  shown*  Some  of  these  phases  necessarily  overlapped  in 
whole  or  in  part*  The  most  notable  areas  of  overlap  were  in 
systems  design  review,  operational  implementation  review,  and 
data  collection  and  analyses.  Explanation  and  discussion  of 
these  phases  will  be  covered  more  fully  under  methodology  below. 

C .  METHODOLOGY 

1 .  Concept 

Study  research  was  directed  towards  accomplishing  the 
objectives  as  stated  in  the  study  requirement.  In  this  sense 
the  study  can  be  considered  goal  oriented.  In  order  to  identify 
problems,  develop  solutions  to  the  problems  and  create  improve¬ 
ments  to  result  in  a  more  effective  and  efficient  system,  the 
study  group  set  out  to  obtain  a  thorough  understanding  of  the 
supply  support  concept  in  general  and  supply  support  requests  in 
particular.  The  basic  approach  was  to  determine  the  basic  rules 
for  submitting  and  requesting  supply  support  and  to  trace  supply 
support  requests  from  the  initial  generation  and  submission  of 
the  requirement  until  the  acceptance  or  rejection  of  the  require¬ 
ment. 


The  "Systems  Approach"  (Appendix  D,  Reference  11)  was 
adopted  as  the  basic  research  methodology,  which  requires  that 
there  should  be  a  plan  for  conducting  a  systems  study  that 
borrows  liberally  from  the  scientific  method  and  dictates  that 
problems  be  analyzed  both  functionally  and  operationally.  Prob¬ 
lems  are  looked  at  as  potential  systems  requiring  input,  pro¬ 
cessing,  output,  control  and  feedback. 

The  systems  approach  requires  that  a  problem  be  attacked 
in  an  orderly  way.  The  problems  must  be  properly  identified, 
appropriate  boundaries  drawn,  investigated  and  models  of  the 
systems  developed.  The  models  are  then  analyzed  and  evaluated 
in  terms  of  systems  requirements  as  stated  by  goals  and  standards 
for  accomplishing  various  actions. 

A  system  has  been  defined  as  an  array  of  components 
designed  to  achieve  an  objective  according  to  a  plan  (Appendix  D, 
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Reference  12).  One  of  the  best  ways  of  depicting  a  system  Is 
the  abstract  depiction  of  an  automatic  data  processing  system  by 
Anthony  Oettlnger  (Appendix  D,  Reference  13)  as  shown  In  Figure 
1-2  below. 

TYPICAL  SYSTEM 


Note  that  the  system  as  depicted  In  Figure  1-2  above  has 
five  basic  components.  This  picture  can  be  used  to  describe  any 
basic  system  whether  manual,  automated  or  a  combination.  SSRs 
were  viewed  as  a  system  and  each  of  its  component  parts  were 
studied  separately  as  well  as  in  terms  of  their  i elatlonships 
with  other  systems  components. 

The  procedure  employed  was  to  determine  the  requirements 
of  the  SSR  system,  the  products  the  system  was  producing,  and  to 
evaluate  these  in  terms  of  the  functions  being  performed  and  the 
organizations  designing  and  using  the  systems. 

A  number  of  study  techniques  were  developed  by  the  team 
of  logistics,  systems,  computer  and  operations  research  analysts. 
This  team  utilized  their  diverse  but  complementary  skills  to 
apply  different  tools  of  analysis  to  the  problems  being  studied. 
The  intent  was  to  look  at  things  in  different  ways  and  to  com¬ 
pare  the  research  results.  This  technique  provided  a  vehicle  to 
permit  both  reinforcement  for  critical  conclusions  and  recommen¬ 
dations,  and  acts  as  a  check  and  balance  system  to  ensure  the 
validity  of  study  results. 
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2.  Study  Techniques.  Thia  section  contains  a  brief  synop¬ 
sis  of  the  essential  tools  of  analysis  used  during  the  course  of 
the  study.  It  is  not  meant  to  be  exhaustive  or  to  provide  com¬ 
plete  coverage  of  all  types  of  research  and  analysis  employed. 

It  is  Intended  to  give  the  reader  a  general  understanding  of  the 
course  of  the  study  to  permit  easier  comprehension  of  the  mate¬ 
rial  contained  in  succeeding  chapters. 

a.  Policies  and  Procedures  Review.  The  study  group 
commenced  the  first  phase  of  the  study  performing  background  and 
document  research  of  all  known  documents,  including  directives, 
regulations,  instructions,  manuals,  containing  policies  or  proce 
dures  relating  to  SSRs.  This  was  supplemented  with  briefings  by 
the  headquarters  level  organizations  of  the  Components  to  gain 
an  insight  in  policies  and  procedures  as  understood  and  promul¬ 
gated  by  the  Components  and  to  determine  their  respective  manage 
ment  philosophies. 

b .  Systems  Design  Analysis 

Once  the  study  team  had  obtained  a  background  in  SSR 
policies  and  procedures,  the  next  step  was  to  review  the  design 
of  the  systems  that  were  developed  by  the  Components  to  imple¬ 
ment  SSR  requirements.  Systems  design  review  was  performed  by 
reviewing  requirements  specifications  and  discussing  the  design 
of  systems  by  the  Systems  Design  Activities  (SDAs)  to  implement 
these  specifications.  Each  of  the  Component  SDAs  were  visited 
to  receive  briefings  on  SSR  and  related  applications  and  copies 
of  documentation  describing  the  design  of  these  systems. 

Study  analysts  prepared  flow  charts  of  the  Component 
systems  design  based  upon  documentation  and  briefings  received 
from  the  SDAs.  Generally,  three  levels  of  flow  charts  were  pre¬ 
pared;  systems  overview,  subsystems  and  application.  The  sys¬ 
tems  overview  shows  the  relationships  among  subsystems  such  as 
provisioning,  cataloging,  technical  or  requirements.  A  sub¬ 
system  chart  depicts  the  relationship  and  interaction  of  appli¬ 
cations  and  an  applications  chart  shows  the  flow  of  data  among 
programs . 

These  charts  were  then  used  to  describe  and  analyze 
systems  design.  The  charts  also  served  as  a  road  map  during  our 
operational  implementation  review  to  determine  the  extent  and 
degree  of  implementation  of  systems  as  designed  by  the  SDA. 

The  following  SDA  activities  were  visited  during  the 
course  of  the  study. 
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Component 

Army 

Navy 

Air  Force 

Marine  Corps 


Defense  Logistics 
Agency 

General  Services 
Administration 


Activity 

Automated  Logistics  Systems  Management 
Activity  (ALMSA) 

Fleet  Material  Support  Office  (FMSO) 

Sacramento  Air  Logistics  Center  (SMALC) 
Ogden  Air  Logistics  Center  (OOALC) 

Marine  Corps  Logistics  Support  Base 
Atlantic  (MCLSBA) 

Defense  Logistics  Agency  Systems 
Automation  Center  (DSAC) 

General  Services  Administration 
Headquarters 


Operational  Implementation  Review 
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the 
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he 
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wn 

below 

: 

Component 

Army 

Navy 

Air  Force 

Marine  Corps 


Defense  Logistics 
Agency 


General  Services 
Administration 


Activity 

Tank-Automotive  Materiel  Readiness  Command 
(TARCOM) 

Troop  Support  and  Aviation  Materiel 
Readiness  Command  (TSARCOM) 

Ships  Parts  Control  Center  (SPCC) 

Sacramento  Air  Logistics  Center  (SMALC) 
Ogden  Air  Logistics  Center  (OOALC) 

Marine  Corps  Logistics  Support  Base 
Atlantic  (MCLSBA) 

Defense  Construction  Supply  Center  (DCSC) 
Defense  Electronics  Supply  Center  (DESC) 
Defense  General  Supply  Center  (DGSC) 

Federal  Supply  Service,  Washington,  D.C. 
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These  activities  represent  a  sample  of  the  total 
spectrum  of  the  SSR  process.  Operational  activities  can  be  clas¬ 
sified  into  two  general  categories;  submitters  and  receivers  of 
SSRs.  A  submitter  is  a  Service  Item  Control  Center  (SICC)  who 
requests  supply  support  from  an  Integrated  Materiel  Manager  who 
is  classified  as  a  receiver.  The  study  group  visited  both  types 
of  activities  during  the  field  research  of  operational  activi¬ 
ties. 


The  purpose  of  these  visits  was  to  obtain  an  under¬ 
standing  of  the  organizational  elements,  functions  and  systems 
affecting  methods  of  requesting  and  obtaining  supply  support. 

The  visits  were  conducted  in  two  parts.  First,  the 
study  group  received  briefings  describing  the  SSR  system  as  the 
operating  activity  understood  it.  These  briefings  covered  the 
organizational  elements  performing  the  provisioning,  cataloging 
and  supply  support  functions;  a  work  flow  description  of  supply 
support  processing  from  preparation  or  receipt  through  comple¬ 
tion;  and  an  overview  of  data  systems  related  to  processing  and 
controlling  SSRs. 

The  second  part  of  the  visit  consisted  of  an  opera¬ 
tional  review  of  the  implementation  of  the  system  as  designed  by 
the  SDA.  Using  the  briefings  from  part  one  as  a  guideline,  the 
study  team  performed  an  on-site  visit  with  operational  personnel 
directly  responsible  for  implementation  and  processing  of  SSR 
systems  and  procedures  at  the  working  level  in  the  actual  opera¬ 
tional  environment.  Study  analysts  traced  SSRs  through  their 
life  cycle,  including  all  major  functions,  events,  processes, 
organizations  and  work  stations  for  both  incoming  and  outgoing 
SSRs. 


After  completion  of  the  visit,  the  team  prepared 
charts  describing  the  SSR  system  from  an  operational  basis. 

Three  types  of  charts  were  prepared  (1)  organization  charts,  (2) 
event  charts,  and  (3)  work  process  flow  charts.  Through  the  use 
of  these  charts  the  team  could  model  the  operational  system,  by 
considering  the  SSR  process  as  a  network.  This  model  of  the 
network  was  then  used  to  understand  and  analyze  the  SSR  system 
in  tens  of  its  events,  work  stations,  organizations,  functions 
and  processes. 

d .  Quantitative  Evaluation 

The  purpose  of  the  quantitative  evaluation  technique 
was  to  apply  an  objective  methodology  to  the  analysis  and  evalua¬ 
tion  of  the  SSR  system  in  order  to  determine  the  relative  effi¬ 
ciency/effectiveness  of  SSR  processing.  During  the  headquarters 
and  field  level  research  the  Components  were  asked  how  they 
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measured  Che  effectiveness  and  efficiency  of  their  SSR  systems, 
what  goals  or  standards  had  been  established  and  what  management 
reports  were  produced  Co  quantitatively  measure  attainment  of 
these  goals . 


The  standard  reply  was  to  the  effect  that  there  were 
no  established  goals  and  standards  other  than  a  general  reference 
to  the  SSR  manual;  and  there  were  no  existing  quantitative  mea¬ 
sures  of  their  SSR  systems.  There  were  no  management  reports 
available  to  the  management  levels  at  headquarters  or  the  opera¬ 
tion  level  activities  that  could  be  used  to  determine  the  per¬ 
formance  of  their  systems  against  SSR  goals  and  standards. 

The  study  group  discussed  the  lack  of  availability 
of  management  reports  with  the  chairman  and  members  of  the  SPG. 
The  study  group  expressed  their  desire  to  perform  a  quantitative 
evaluation  of  the  SSR  system  and  requested  approval  of  a  plan  to 
collect  and  analyze  SSR  transactions.  Authority  was  granted  to 
the  study  group  to  prepare  an  evaluation  plan  and  and  to  estab¬ 
lish  a  data  collection  and  analysis  system.  The  development  and 
accomplishment  of  this  plan  will  be  discussed  in  detail  in 
Volume  III  of  this  Report. 

e.  Problem  Identification 


As  part  of  our  overall  systems  approach  to  the  con¬ 
duct  of  this  study,  the  study  group  tried  to  identify  actual  or 
potential  problems  in  the  SSR  system.  The  intent  was  to  expand 
upon  the  initial  problems  contained  in  the  study  plan  as  reported 
by  the  SPG.  The  Components  were  asked  during  headquarters  level 
research,  field  research  and  during  SPG  meetings  to  document  and 
provide  to  the  study  group  any  problems  being  experienced  or 
foreseen;  and  to  recommend  changes  to  the  SSR  systems  and  proce¬ 
dures  to  correct  these  problems  or  otherwise  improve  SSR  pro¬ 
cessing. 


These  problems  were  collected  during  the  course  of 
the  study  and  considered  in  conjunction  with  other  techniques  of 
analysis.  The  problem  identification  and  analysis  technique 
will  be  treated  more  fully  in  Chapter  III  of  Volume  I. 

f.  Tests.  Another  technique  of  analysis  used  by  the 
8 tudy  group  was  the  use  of  tests  to  analyze  specific  propositions 
or  hypotheses.  Two  tests  were  established  by  the  study  group. 

The  first  test  was  to  determine  the  feasibility  of  transmitting 
and  receiving  SSRs  over  AUTODIN  and  the  feasibility  of  electrical 
transmission  of  technical  data  using  telecommunications.  The 
other  test  was  a  validation  test  that  processed  sample  SSR  trans¬ 
actions  through  the  Component's  actual  validation  programs  in 
the  test  mode.  These  tests  are  discussed  in  Volume  III. 
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g.  Questionnaires  .  Questionnaires  were  used  to  supple¬ 
ment  other  types  of  analyses.  They  were  used  to  obtain  informa¬ 
tion  not  available  from  other  sources,  find  out  if  certain  in¬ 
formation  was  being  used,  how  certain  processes  were  being 
accomplished  and  to  solicit  opinion.  Three  types  were  used;  a 
problems/  recommendations  opinion  survey,  validation  analysis 
and  data  element  usage  questionnaire.  The  questionnaires  were 
integrated  into  Volumes  II  and  III  of  the  Report. 

D .  REPORT  ORGANIZATION  AND  FORMAT 

1 .  Terminology 

Generally  standard  terms  as  used  in  the  fields  of  logis¬ 
tics,  systems,  data  processing,  mathematics  and  statistics  will 
be  used.  References  to  and  use  of  definitions  of  terms  con¬ 
tained  in  DoD  publications  or  directives  will  be  made  whenever 
possible. 

A  list  of  all  acronyms  used  in  this  Report  are  contained 
in  the  appendices  for  ready  reference. 

Specialized  terms  will  be  defined  in  place  where  first 
used.  Definitions  that  are  considered  new  or  that  have  been 
developed  by  the  study  group  will  be  highlighted  and  fully 
defined  in  the  section  of  the  report  where  they  are  described. 

2 .  References 


A  common  referencing  scheme  will  be  used  throughout  the 
report.  A  reference  will  be  assigned  a  number  the  first  time  it 
is  used  in  the  Report.  Thereafter  the  number  assigned  to  the 
documentary  reference  will  be  used.  A  list  of  all  cited  refer¬ 
ences  may  be  found  in  the  appendices. 

During  the  course  of  the  study  numerous  publications  and 
documents  were  researched.  Many  of  these,  while  not  specifically 
referred  to  in  the  report,  have  been  used  during  the  course  of 
the  study.  References  that  have  not  been  cited  in  the  report, 
but  are  considered  of  major  significance  will  be  listed  in  the 
bibliography  contained  in  the  appendices. 

3.  Report  Outline.  The  Report  has  been  divided  Into  three 
volumes  because  of  the  complexity  of  the  study  and  the  range  and 
depth  of  research  and  analysis. 
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a.  Volume  I  -  Baatc  Report.  Volume  I  is  the  basic 
report  and  contains  the  study  assignment  and  describes  the  study 
approach,  methodology,  and  research  techniques  used  throughout 
the  course  of  the  study.  A  description  of  the  functional  re¬ 
quirements  of  the  system  are  presented  and  a  conceptual  system 
is  depicted  to  provide  the  reader  with  the  basic  knowledge 
required  to  have  an  understanding  of  the  analysis,  conclusions 
and  recommendations  presented.  The  analysis,  conclusions  and 
recommendations  are  based  upon  the  detailed  research  presented 
in  Volumes  II  and  III. 

b.  Volume  II  -  Systems  Design  and  Implementation.  Vol¬ 
ume  II  contains  the  results  of  the  detailed  systems  design  and 
operational  implementation  research.  Part  I  provides  a  descrip¬ 
tion  of  systems  designed  by  each  of  the  Components  to  implement 
the  functional  requirements  presented  in  Volume  I.  Part  II 
describes  the  operational  systems  actually  implemented  by  the 
Components  at  the  time  of  the  study.  The  conceptual  system  is 
used  as  a  basis  of  understanding  the  design  and  Implementation 
of  systems  in  terms  of  the  functional  requirements. 

c .  Volume  III  -  Performance  Evaluation.  Volume  III 
discusses  the  quantitative  evaluation  of  the  SSR  system,  the 
AUTOD I N/ TE L£ FAX  Test  and  the  Ed i t / Va 1 id a t i o n  Analysis. 

A.  Appendices  .  The  appendices  contain  material  which  is 
considered  reference  documentation  or  study  material  developed 
by  the  study  group  during  the  course  of  the  study  that  is  con¬ 
sidered  of  major  importance  but  is  too  lengthy  to  be  Included  in 
the  main  body  of  the  report. 

5.  Report  Orientation.  The  report  is  written  for  the 
upper,  middle  and  operational  management  levels.  As  such,  some 
readers  may  receive  varying  degrees  of  perception,  understanding 
and  detail.  Those  readers,  who  desire  to  know  only  what  the 
assignment  was  and  what  the  results  were,  may  wish  to  limit  their 
reading  to  Chapters  I  and  VI  of  the  basic  report.  Volume  I. 

Middle  level  managers  may  wish  to  read  the  basic  report  in  its 
entirety  to  obtain  an  understanding  of  the  management  environ¬ 
ment,  system  requirements  and  the  comparative  analysis  of  the 
policy,  procedures,  systems  design  and  implementation.  For 
those  desiring  a  more  complete  review  and  understanding  of  the 
supply  support  scenario,  we  commit  to  an  exhaustive  reading  of 
the  detailed  research  in  Volumes  II  and  III  in  addition  to  the 
basic  report . 
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CHAPTER  II 


MANAGEMENT  ENVIRONMENT 


A.  POLICY 


The  management  environment  consists  of  the  policies,  proce¬ 
dures,  organizations  and  functions  needed  to  design,  develop  and 
implement  systems  necessary  to  accomplish  supply  support  request 
(SSR)  processing.  The  basic  policies,  principles  and  objectives 
governing  supply  support  in  the  Department  of  Defense  (DoD)  are 
contained  in  four  DoD  Directives. 

:  DoD  Directive  4100.35 

:  DoD  Directive  4000.19 

:  DoD  Directive  4140.26 

:  DoD  Directive  5030.47 

These  directives  provide  the  overall  authority  for  implement¬ 
ing  policy  and  procedures  contained  in  other  DoD  Instructions 
and  Manuals. 

DoD  Directive  4100.35  (Appendix  D,  Reference  14)  establishes 
policy  and  assigns  responsibility  for  carrying  out  the  integrated 
logistic  support  program  as  an  integral  part  of  the  acquisition 
process  for  the  life  cycle  support  of  systems/equipments  pro¬ 
cured  by  DoD  Components.  Integrated  logistic  support  is  defined 
as  the  composite  of  all  the  support  considerations  necessary  to 
assure  the  effective  and  economical  support  of  a  system  for  its 
life  cycle.  Supply  support  is  one  of  the  principal  elements  of 
integrated  logistic  support. 

Basic  policies  and  principles  for  interservice,  interdepart¬ 
mental  and  interagency  support  are  contained  in  DoDD  4000.19 
(Appendix  D,  Reference  15).  This  directive  specifies  that  each 
DoD  Component  is  responsible  for  providing  supply  support  for 
its  own  forces  or  arranging  common  supply  support  with  other 
Components  in  accordance  with  the  responsibility  for  performance 
of  such  support  as  assigned  by  the  Secretary  of  Defense. 

Responsibilities  for  performance  of  supply  support  for  con¬ 
sumable  items  are  designated  by  DoDD  4140.26  (Appendix  D,  Refer¬ 
ence  16),  through  integrated  materiel  management  assignments. 
These  assignments  are  made  under  the  concept  that  there  will  be 
only  one  wholesale  manager  for  any  sumable  item  used  in  DoD. 
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This  Directive  provides  criteria  for  the  assignment  of  consum¬ 
able  items  to  the  Military  Services  and  Defense  Agencies  for 
integrated  materiel  management.  Integrated  materiel  management 
encompasses  the  exercise  of  total  DoD  or  Federal  Government 
management  responsibility  for  a  Federal  Supply  Group/Federal 
Supply  Class  (FSG/FSC),  commodity  or  item  by  a  single  Component. 
Normally,  it  includes  computation  of  requirements,  and  the  func¬ 
tions  of  funding,  budgeting,  storing,  issuing,  cataloging,  stan¬ 
dardizing,  and  procuring.  This  Directive  also  authorizes  the 
Defense  Logistics  Agency  to  develop  and  publish  a  manual  in  con¬ 
cert  with  other  DoD  Components  to  provide  implementing  policy 
and  procedures  for  the  integrated  materiel  management  of  con¬ 
sumable  items  throughout  DoD. 

DoDD  5030.47  (Appendix  D,  Reference  17)  delineates  the 
responsibilities  and  relationships  between  the  General  Services 
Administration  (GSA)  and  DoD  for  integrated  materiel  management. 
The  Defense  Logistics  Agency  acting  under  the  mission  assigned 
by  DoDD  5105.22  (Appendix  D,  Reference  18)  is  assigned  the 
responsibility  for  development  of  implementing  policies  and  pro¬ 
cedures  for  supply  support  under  the  National  Supply  System 
Concept . 

These  DoD  Directives  establish  the  authority  and  framework 
for  the  development  of  implementing  policy  and  procedures  for 
the  integrated  materiel  management  of  consumable  items  not  only 
throughout  DoD,  but  for  the  Federal  Government. 

B.  PROCEDURES 


Procedures  for  requesting  and  obtaining  supply  support  are 
contained  in  a  number  of  documents.  The  principal  document  is 
the  Defense  Integrated  Materiel  Management  Manual  for  Consumable 
Items  (Appendix  D,  Reference  9).  This  manual  is  published  and 
maintained  by  the  Defense  Logistics  Agency  under  the  authority 
of  DoDD  4140.26  (Appendix  D,  Reference  16).  This  manual  was 
developed  by  DoD  Task  Groups  established  to  implement  the  recom¬ 
mendations  of  the  Item  Logistics  Management  Data  (ILMD)  Study. 

The  manual  covers  two  main  functional  areas,  the  assignment 
of  integrated  materiel  management  responsibilities  among  DoD 
Components  for  classes  of  items  through  the  use  of  Item  Manage¬ 
ment  Coding  (IMC)  criteria  and  the  use  of  SSRs  to  request  and 
receive  supply  support.  Hereinafter  this  manual  will  be  re¬ 
ferred  to  as  the  IMM  Manual.  References  to  IMC  procedures  or 
SSR  procedures  will  refer  to  those  contained  in  the  IMM  Manual 
unless  another  specific  citation  is  made.  IMC  and  SSR  proce¬ 
dures  are  interrelated;  this  will  be  explored  more  fully  during 
the  course  of  this  Report. 
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There  are  a  number  of  ocher  documents  that  contain  policies, 
criteria  or  procedures  for  the  submission  of  SSRs,  despite  the 
intent  of  the  ILMD  Study  to  eliminate  the  duplication  of  SSR 
procedures.  These  documents  are  discussed  in  Volume  I,  Chapter 
V. 

C.  SUPPLY  SUPPORT  CONCEPT 

The  requirement  for  supply  support  generally  derives  from 
provisioning  of  end  items  of  materiel  as  described  in  DoD  direc¬ 
tives  for  provisioning  (Appendix  D,  References  5  and  19).  Pro¬ 
visioning  is  the  management  process  for  determining  and  acquiring 
the  range  and  depth  (quantity)  of  support  items  necessary  to 
operate  and  maintain  an  end  item  of  materiel  for  an  initial 
period  of  service.  During  the  provisioning  process,  the  Mili¬ 
tary  Services  determine  items  required  to  support  the  equipment 
and  the  method  of  support  for  these  items.  Figure  II-l  pic- 
torially  portrays  the  supply  support  process  in  the  form  of  a 
supply  support  tree. 

1.  Item  Selection/Coding.  The  supply  support  process  com¬ 
mences  during  the  item  selection  and  coding  processes  as  indi¬ 
cated  in  the  top  block  in  the  chart.  At  this  time  the  provi¬ 
sioning  activity  determines  maintenance  significant  items  and 
applies  Source,  Maintenance  and  Recoverability  (SM&R)  Codes  in 
accordance  with  the  Joint  Regulation  governing  the  use  and 
application  of  SM&R  Codes  (Appendix  D,  Reference  20).  Items 
that  are  maintenance  significant  and  source  coded  in  the  P_ 
series,  are  reviewed  and  IMC  applied.  P_series  codes  are 
applied  to  those  items  that  are  being  recommended  for  procure¬ 
ment  action. 

2.  Method  of  Management.  As  a  result  of  IMC,  the  provi¬ 
sioning  activity  determines  if  the  item  is  to  be  retained  by  the 
provisioning  Service  or  managed  by  an  IMM.  IMC  is  accomplished 
in  accordance  with  the  criteria  contained  in  the  IMM  Manual.  If 
the  item  is  Service  retained,  supply  support  for  the  item  flows 
through  the  branches  on  the  left  side  of  the  tree  in  Figure  II-l. 

3.  Retained  Items.  The  provisioning  activity  must  then 
determine  if  a  Service  retained  item  will  be  managed  by  the 
provisioning  activity  itself  referred  to  as  the  Program  Inven¬ 
tory  Control  Point  (ICP)  or  whether  it  will  be  managed  by  an¬ 
other  activity  in  the  same  Service  referred  to  as  the  Support 
ICP. 

a.  Program  ICP.  The  Program  ICP  block  of  the  third 
tier  represents  those  items  that  are  managed  by  the  program 
inventory  control  point  or  provisioning  activity.  There  are 
four  general  categories  of  retained  items  that  will  be  managed 
by  the  provisioning  activity. 


(1)  New  PIO  PN.  Part  numbered  items  that  cannot  be 
associated  with  an  existing  National  Stock  Number  (NSN)  and  are 
manufactured  by  the  equipment  manufacturer  will  generally  be 
procured  on  a  Provisioned  Item  Order  (PIO). 

(2)  New  Vendor  PN.  Part  numbered  items  are  items 
that  cannot  be  associated  with  an  existing  NSN  and  are  not  manu¬ 
factured  by  the  equipment  manufacturer.  The  items  may  be  pro¬ 
cured  on  a  PIO  or  directly  from  the  vendor  used  by  the  equipment 
manufacturer  or  another  vendor. 

(3)  Inactive  NSN.  The  part  number  cross  references 
to  an  NSN  for  which  there  is  no  current  recorded  user. 


(A)  Active  NSN.  The  item  o 
stock  number  that  is  managed  by  the  prov 

b .  Support  ICP 

The  Support  ICP  is  another  I 
that  is  responsible  for  providing  supply 
types  of  items  for  that  Service.  Genera 
within  a  Service  are  assigned  on  an  FSC 
oriented  consumable  items  or  an  item  bas 
items  that  are  Service  retained. 

The  Program  ICP  must  request 
port  ICP.  Although  the  DODSSR  procedure 
some  of  the  Services  use  the  DODSSR  proc 
port  and  others  use  their  own  intraservi 
mats.  This  will  be  discussed  in  more  de 
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As  is  the  case  with  Program  ICP  managed 
part  number  and  NSN  items  may  be  supported  by  a  Supp 
However,  some  Services  provide  that  any  new  retained 
ing  the  system  will  be  managed  by  the  Program  ICP. 
do  not  generally  procure  on  the  prime  contract,  alth 
Force  has  provisions  for  the  Support  ICP  to  request 
ICP  to  procure  on  the  end  item  contract. 
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A.  IMM  Items 


Items 

dldates  for  re 
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the  Service  in 
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number  of  diff 
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that  meet  the  criteria  for  IMM  are  considered  can- 
questing  supply  support  from  an  IMM.  If  a  support 
criteria  for  IMM  as  stated  in  the  IMM  Manual  and 
dividual  requirements  computation  criteria  for 
end  item  being  provisioned,  the  provisioning 
request  supply  support  from  an  IMM.  There  are  a 
erent  ways  to  request  supply  support.  Different 
scussed  in  Chapter  V,  Volume  I,  and  Volume  III. 
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There  are  three  different  types  of  IMM  assignments; 

CIMM,  WIMM,  and  Lead  ICP. 

a .  C IMM  Items 

A  Commodity  Integrated  Materiel  Manager  (CIMM)  is 
an  activity  or  agency  designated  to  exercise  integrated  materiel 
management  at  the  wholesale  level  for  a  commodity  oriented  FSG/ 
FSC  or  item  on  a  DoD  or  Federal  Government-wide  basis. 

Both  part  number  and  NSN  items  may  be  forwarded  to 
an  IMM  for  supply  support.  Another  category  includes  items  with 
a  permanent  system  control  number  (PSCN).  A  PSCN  is  a  unique 
control  number  assigned  by  the  Defense  Logistics  Services  Center 
(DLSC)  in  the  functional  program  area  of  standardization  to 
enable  establishment  and  mechanized  processing  of  data  associated 
with  an  item  which  does  not  qualify  for  assignment  of  an  NSN. 

At  such  time  as  an  item  with  a  PSCN  qualifies,  an  NSN  will  be 
ass lgned . 


There  are  very  few  items  with  PSCNs  forwarded  to 
IMMs  for  supply  support.  Statistics  on  the  volume  of  these 
items  are  presented  in  Volume  III. 

b.  WIMM  Items .  A  Weapons  Integrated  Materiel  Manager 
(WIMM),  is  a  Service  ICP  that  performs  DoD  or  Federal  Government¬ 
wide  wholesale  integrated  materiel  management  functions  for  as¬ 
signed  items.  Current  SSR  procedures  permit  both  NSN  and  part 
number  items  to  be  submitted  for  supply  support.  Part  numbered 
items  are  restricted  to  joint  service  provisioning  actions  for 
WIMM  items. 

c.  Lead  ICP  Items  .  Lead  ICP  items  are  nonconsumable 
items  covered  under  the  joint  regulation  for  elimination  of 
duplication  of  management  of  nonconsumable  items  (Appendix  D, 

Re f  erence  21 )  . 

5.  Support  Determinations.  Regardless  of  the  method  of 
management,  i.e.,  Service  or  IMM,  supply  support  determinations 
must  be  made.  Two  basic  determinations  performed  by  the  manager 
are  method  of  support  and  level  of  support. 

a.  Method  of  Support.  Method  of  support  involves  the 
determination  of  whether  the  item  will  be  stocked  or  not  stocked 
in  the  supply  system,  and  whether  the  item  will  be  centrally  or 
locally  managed.  Acquisition  advice  codes  (AACs)  will  usually 
be  assigned  to  reflect  these  management  determinations. 

b.  Level  of  Support.  Level  of  support  involves  the 
determination  of  the  depth  or  quantity  of  items  to  stock.  If 
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an  item  is  stocked;  the  manager  must  forecast  requirements, 
determine  the  availability  of  assets,  perform  requirements  com¬ 
putations,  and  establish  and  release  backorders  to  complete  the 
supply  support  process. 

6.  Supply  Support  Boundary 


A  synopsis  of  the  supply  support  concept  in  order  to 
show  where  SSRs  fit  in  the  total  supply  support  picture.  The 
main  thrust  of  this  study  is  depicted  by  the  boundary  as  shown 
by  the  dotted  line  in  Figure  II-l.  The  primary  concentration  of 
the  study  was  on  SSRs  for  CIMM  and  WIMM  items  in  accordance  with 
the  IMM  Manual. 

The  study  group  was  granted  authority  by  the  Special  Pro 
jects  Group  (SPG)  for  Provisioning  to  review  other  types  of  sup¬ 
ply  support  requests.  These  "SSRs"  were  reviewed  on  a  general 
basis  for  comparison  purpose  only.  Intraservice  "Supply  Support 
Requests"  were  reviewed  to  determine  to  what  extent  the  DODSSR 
procedures  were  being  used  for  intra  as  well  as  interservice  use 
Nonconsumable  items  were  also  reviewed  because  they  represent  a 
purely  manual  system  similar  to  the  system  that  was  used  prior 
to  May  1976  for  nonprovisioning  SSRs.  In  addition,  the  study 
group  wanted  to  determine  the  relative  volume  and  similarity  of 
Nonconsumable  Item  Materiel  Support  Request  (NIMSRs)  to  SSRs. 

D .  ORGANIZATIONS 

The  organizations  responsible  for  planning,  designing  and 
implementing  SSR  systems  also  have  an  impact  upon  SSR  processing 
through  the  organizational  placement  of  related  SSR  functions. 

As  shown  in  Figure  II-2,  there  generally  are  three  types  of  orga 
nlzatlons  involved;  headquarters,  systems  design  activities 
( SDAs )  and  operating  activities. 

ORGANIZATIONAL  RELATIONSHIP 


Figure  II-2 
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1 .  Department 

The  Assistant  Secretary  of  Defense  (Manpower,  Reserve 
Affairs  and  Logistics) (ASD(MRA&L) )  and  the  General  Services  1 

Administration,  Federal  Supply  Service  (GSA-FSS)  promulgate  the 
policy,  objectives  and  general  procedures  for  SSRs  and  related 
functions.  The  policies  and  procedures  contained  in  the  IMM 
Manual  have  been  jointly  agreed  to  by  DoD  and  GSA. 

The  Directorate  for  Supply  Management  Policy  in  ASD(MRA&L) 
is  responsible  for  the  IMM  Manual.  The  SSR  portion  of  this 
manual  comes  under  the  Supply  Policy  and  Programs  Division  and 
the  IMC  portion  of  the  manual  comes  under  the  Materiel  Manage¬ 
ment  Systems  Division. 

The  Federal  Supply  Service,  Office  of  Customer  Service 
and  Support,  is  the  responsible  organization  in  GSA  for  both  IMC 
and  SSR  procedures  in  the  IMM  Manual.  j 

The  general  functional  requirements  statement  for  SSRs 
is  contained  in  Chapter  IV  and  Appendix  E  of  the  IMM  Manual.  i 

The  IMM  Manual  provides  implementing  policy  and  procedures  for  I 

the  preparation,  processing,  and  control  of  SSRs  to  provide 
supply  support  in  accordance  with  the  support  concept  described 
above.  The  procedures  are  applicable  to  each  Service  as  a  WIMM 
or  Service  Item  Control  Center  (SICC),  and  to  all  CIMMs  under 
the  integrated  management  concept  for  multiservice  used  weapon 
systems  oriented  consumable  or  commodity  oriented  items. 

Responsibilities  and  tasks  are  assigned  and  outlined  by 
SICC  and  IMM.  The  usage  of  the  term  SICC  denotes  the  provision¬ 
ing  activity  or  SSR  submitter  and  IMM  designates  the  CIMM  or 
WIMM  as  receiver  or  processor  of  the  request  for  supply  support. 

The  major  functional  tasks  assigned  to  submitters  and  receivers 
are  outlined  under  functions  below. 

2 .  Se r v 1 c e / Age nc y  Headquarters 

The  Service/Agency  Headquarters  elements  are  generally 
responsible  for  the  development  of  the  detailed  functional 
requirements  statements  used  to  implement  the  policies  and  pro¬ 
cedures  Issued  by  the  departmental  level.  In  some  cases  the 
responsibility  for  the  functional  requirements  statement  may  be 
delegated  to  a  lower  organizational  echelon.  The  functional 
requirements  statement  or  specification  provides  guidance  to  the 
S  D As  for  the  development  of  systems  to  implement  requirements 
for  SSR  processing  in  accordance  with  the  conventions  specified 
in  the  SSR  Procedures. 
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Appendix  E  of  the  SSR  Procedures  provides  conventions 
for  the  preparation  and  submission  of  SSRs  including  mechanized 
formats  and  detailed  procedures  for  entry  of  required  data  ele¬ 
ments  and  codes  for  SSR  transactions.  These  conventions  are  the 
rules  governing  the  preparation,  submission,  processing,  and 
control  of  SSRs.  These  rules  provide  the  vehicle  for  the  design 
of  systems  to  implement  the  functional  requirements  as  stated  in 
SSR  policies  and  procedures. 

Functional  requirements  specifications  may  vary  a  great 
deal  in  terms  of  degree  of  generality  or  specificity  among 
S er v i c e s / Ag enc i e s .  In  some  cases  the  Headquarters  level  will 
prepare  a  general  or  conceptual  requirement  and,  in  others,  a 
detailed  requirement  will  be  developed  specifying  inputs,  out¬ 
puts  and  procedures  in  great  detail.  Organizational  placement 
of  like  functions  may  vary  widely  among  the  Components. 

a .  Army 


The  Department  of  Army  Materiel  Development  and 
Readiness  Command  (DARCOM)  is  the  official  point  for  the  develop¬ 
ment  of  functional  requirements  statements;  however,  some  of 
these  duties  have  been  delegated  to  the  Catalog  Data  Agency  (CDA) 
in  New  Cumberland,  Pennsylvania.  In  addition  to  the  functional 
responsibility  for  SSRs,  CDA  has  the  functional  responsibility 
for  IMC  programs,  item  identification  data  and  cataloging.  Func¬ 
tional  responsibilities  for  provisioning  and  requirements  deter¬ 
mination  remain  at  DARCOM  Headquarters  in  the  Directorate  for 
Materiel  Management  (DMM).  The  Associate  Director  for  Mainte¬ 
nance  in  DMM  has  the  assignment  for  provisioning  while  the  Asso¬ 
ciate  Director  for  Requirements  and  Resources  has  the  assignment 
for  requirements  determination. 

The  DODSSR  Study  assignment  requested  the  Components 
to  designate  their  SPG  member  as  the  Component  contact  point  for 
the  study.  DARCOM  participation  in  the  SPG  is  the  functional 
responsibility  of  the  Maintenance  Directorate  in  DARCOM.  How¬ 
ever,  since  the  functional  responsibility  for  SSRs  is  assigned 
to  CDA,  DARCOM  designated  CDA  as  the  DARCOM  point  of  contact  for 
the  DODSSR  Study. 

Although  the  responsibility  for  developing  functional 
specifications  for  system  design  has  been  assigned  to  CDA,  opera¬ 
tional  control  of  the  functional  elements  at  the  SDA  and  operating 
activities  Implementing  the  system  is  retained  at  DARCOM. 

b.  Navy.  ihe  Naval  Supply  Systems  Command  (NAVSUP)  is 
responsible  for  development  of  functional  requirements  for  the 
Navy.  The  Deputv  Commanders  for  Fleet  Support  and  Supply  Opera¬ 
tions,  and  Plans,  Policy  and  Programs  Development  are  responsible 
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for  SSR  and  related  functional  areas.  The  Provisioning,  Con¬ 
figuration  and  Allowance  Branch  of  the  Integrated  Logistics 
Support  Division  of  Supply  Operations  is  responsible  for  imple¬ 
mentation  of  policy  and  development  of  functional  requirements 
statements  for  provisioning  and  supply  support  requests.  Rep¬ 
resentation  to  the  SPG  is  also  provided  by  this  organization. 
Item  identification,  IMC  and  cataloging  is  the  functional 
responsibility  of  the  Technical  and  Interservice  Program  Branch 
of  the  Logistics  Plans  and  Policy  Control  Division  under  the 
Deputy  Commander  for  Plans,  Policy  and  Programs.  Responsibility 
for  requirements  determination  processes  come  under  the  Opera¬ 
tions  and  Inventory  Analysis  Staff  of  the  Deputy  Commander  of 
Plans,  Policy  and  Programs. 

c .  Air  Force 


The  Air  Force  Logistics  Command  (AFLC)  is  responsible 
for  the  development  of  functional  requirements  for  Air  Force 
applications.  The  Deputy  Chief  of  S t a f f / Log i s t ics  Operations  19 
organizationally  responsible  for  SSR  and  related  functions  as 
outlined  above.  However,  these  functions  are  spread  among  a 
number  of  different  offices  or  directorates.  The  Interservice 
and  Interagency  Support  Office  served  as  the  Air  Force  office  of 
primary  responsibility  for  the  IMM  Manual.  This  includes  both 
SSR  and  IMC  procedures.  Provisioning  functions  are  performed  by 
the  Provisioning  and  Data  Management  Branch;  item  identification 
by  the  Materiel  Identification  Branch;  and  cataloging  by  the 
Cataloging  Office  of  the  Directorate  of  Logistics  Management. 
Requirements  determination  is  the  responsibility  of  the  Direc¬ 
torate  of  Materiel  Requirements. 

AFLC  SPG  representation  is  provided  by  the  provi¬ 
sioning  organization.  However,  the  contact  point  for  the  SSR 
Study  assigned  by  AFLC  was  from  the  Interservice  and  Interagency 
Support  Office. 

d.  Marine  Corps.  The  Material  Division  of  the  Deputy 
Chief  for  Installations  and  Logistics  is  responsible  for  devel¬ 
opin'  policy  to  implement  SSR  and  related  functions.  The  Marine 
Corps  Logistics  Support  Base,  Atlantic  (MCLSBA)  at  Albany, 
Georgia,  has  been  delegated  the  responsibility  for  developing 
functional  specifications  for  the  design  and  development  of 
systems  to  accomplish  these  functions. 

e .  Defense  Logistics  Agency 

There  are  two  directorates  in  DLA  Headquarters  re¬ 
sponsible  for  SSR  and  related  functions:  the  Supply  Operations 
Directorate  and  the  Technical  and  Logistics  Services  Directorate. 
Requirements  specifications  for  SSRs  and  IMC  are  developed  by 
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the  Logistics  Programs  Division  of  the  Supply  Operations  Direc¬ 
torate.  Requirements  determination  is  the  functional  responsi¬ 
bility  of  the  Supply  Management  Division  of  the  Supply  Operations 
Directorate . 


The  Logistics  Programs  Division  provides  representa¬ 
tion  on  the  SPG  and  is  responsible  for  coordination  of  DLA 
policy  for  provisioning  in  coordination  with  other  Federal 
Components.  In  addition,  this  organization  is  responsible  for 
the  administration,  coordination  and  publication  of  the  IMM 
Manual  containing  DoD  policy  and  procedures  for  SSRs  and  IMC. 

This  includes  responsibility  for  implementation  of  the  IMM 
Manual  by  DLA. 

The  Cataloging  and  Technical  Information  Division 
of  the  Technical  and  Logistics  Services  Directorate  provides 
policy  guidance  for  item  identification  and  cataloging  functions; 
however,  the  DLA  Systems  Automation  Center  (DSAC)  has  been  dele¬ 
gated  the  responsibility  for  preparing  requirements  specifica¬ 
tions  for  these  functional  areas.  Although  the  Supply  Operations 
Directorate  has  the  functional  design  responsibility  for  SSRs 
and  IMC,  the  operating  elements  at  the  Defense  Supply  Centers 
using  the  systems  under  the  design  control  of  Supply  Operations 
are  under  the  operational  control  of  the  Technical  and  Logistics 
Services  Directorate. 

f .  General  Services  Administration 

The  Assistant  Commissioner  for  Customer  Service  and 
Support  of  the  Federal  Supply  Service  is  responsible  for  policy 
and  functional  requirements  development  for  all  functional  areas 
related  to  SSRs.  The  Logistics  Data  Management  Division  is  the 
focal  point  for  these  functions,  provides  representation  to  the 
SPG  and  acts  as  the  contact  point  for  the  DODSSR  Study. 

In  accordance  with  an  agreement  with  DoD,  GSA  co¬ 
ordinates  policy  and  requirements  for  supply  support  of  civil 
agencies  with  DLA. 

3 •  Systems  Design  Activities  (SDAs) 
a .  General 


The  systems  design  activities  are  responsible  for 
the  development  of  systems  to  implement  the  detailed  functional 
requirements  statements  prepared  by  the  headquarters  level  activ¬ 
ities.  This  includes  the  development  of  the  conceptual  design 
of  the  system  to  accomplish  the  functions  outlined  in  the  re¬ 
quirements  specification.  Depending  upon  the  degree  of  defini¬ 
tion  provided  in  the  requirements  specification,  the  SDA  may 
prepare  a  detailed  functional  requirements  specification  to 
further  delineate  system  requirements. 
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The  SDA  is  responsible  for  determining  how  the  re¬ 
quirement  will  fit  in  with  existing  systems  and/or  application 
Systems  design  specifications  show  the  relationship  of  a  given 
requirement  to  other  systems  or  functional  areas  and  define 
inputs,  outputs,  files  and  major  processes.  Requirements  for 
ADP  programs  are  specified  and  programming  specifications  are 
developed  . 


Computer  programs  are  developed  using  the  program 
specifications.  These  programs  may  be  tested  in  conjunction 
with  the  operating  activities  that  use  or  implement  the  programs. 

Manual  systems  are  not  usually  designed  by  SDAs  . 
Operating  activities  usually  design  and  develop  manual  systems 
themselves  based  upon  the  requirements  specifications  or  other 
procedures  provided  by  the  headquarters  level  activities. 

b.  Army.  The  Automated  Logistics  Management  Systems 
Activity  (ALMSA)  located  at  St. Louis,  Missouri,  is  the  systems 
design  activity  for  development  of  computer  systems  and  programs 
for  the  Army's  Commodity  Command  Standard  System  (CCSS).  System 
design  requirements  flow  from  DARCOM  through  CDA  for  SSRs  and 
directly  from  DARCOM  for  other  functional  areas.  Operational 
control  is  exercised  by  DARCOM. 

c.  Navy.  The  Fleet  Material  Support  Office  (FMSO) 
located  at  Mechanicsburg,  Pennsyvlania,  is  the  systems  design 
activity  for  the  development  of  automated  systems  for  the  Navy's 
Uniform  Inventory  Control  Point  (UICP)  System.  Requirements 
specifications  from  NAVSUP  flow  to  FMSO  and  are  coordinated  with 
the  ICPs.  Operational  control  is  also  exercised  by  NAVSUP. 

d .  Air  Force 


The  AFLC  prepares  detailed  functional  requirements 
statements  which  are  provided  to  the  system  design  activities 
for  development  of  automated  systems.  Some  of  the  automated 
systems  are  centrally  designed,  developed  and  programmed  at 
AFLC;  however,  the  applications  for  provisioning  and  supply  sup¬ 
port  requests  were  designed  and  developed  at  ALCs  for  AFLC. 

The  office  of  primary  interest  (OPR)  for  SSRs  pre¬ 
pares  a  detailed  functional  requirements  specification  which  is 
forwarded  via  the  Directorate  of  ADP  Resources  at  AFLC  to  the 
ASD  at  McClellan  Air  Force  Base  at  Sacramento,  California.  The 
computer  systems  design  is  then  developed  by  the  Data  Automation 
Branch  of  the  Comptroller.  Although  the  Data  Automation  Branch 
personnel  work  with  people  at  SMALC  in  the  development  of  auto¬ 
mated  systems,  the  Comptroller  is  organizationally  placed  under 
the  base  commander  rather  than  the  ALC . 
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The  automated  system  for  provisioning  was  developed 
by  Data  Automation  of  the  Comptroller  at  Hill  Air  Force  Base. 

The  OPR  for  the  provisioning  function  at  AFLC  it;  the  Provision¬ 
ing  and  Data  Management  Branch  of  the  Directorate  of  Logistics 
Management.  The  provisioning  requirements  statement  developed 
by  the  provisioning  branch  at  AFLC  was  forwarded  to  Hill  Air 
Force  Base  via  the  Directorate  of  ADP  Resources  at  AFLC.  As  at 
Sacramento,  the  Comptroller  is  under  the  command  control  of  the 
base  commander  and  is  not  organizationally  placed  directly  under 
the  AL  C . 

e.  Marine  Corps  .  The  MCLSBA  at  Albany,  Georgia,  is 
responsible  for  the  design  and  development  of  automated  systems 
for  logistics  applications  in  the  Marine  Corps.  The  complete 
responsibility  for  the  development  of  functional  specifications, 
computer  systems  design  and  operational  implementation  resides 
at  Albany.  Provisioning  and  supply  support  request  processing 
was  manually  performed  during  field  research  at  Albany.  The 
automation  of  these  areas  was  in  the  conceptual  design  stage  at 
that  t  lme . 


The  DLA  Systems  Automation  Center  at  Columbus,  Ohio, 
is  assigned  responsibility  for  the  development  of  computer  sys¬ 
tems  for  logistics  application  for  the  Defense  Supply  Centers 
(DSCs).  Functional  requirements  specifications  for  SSR  and 
related  applications,  except  the  technical  subsystem,  are  devel¬ 
oped  by  the  Supply  Operations  Directorate  at  DLA  Headquarters. 
Cataloging  and  technical  applications  are  under  tht  policy 
guidance  of  the  Technical  and  Logistics  Services  Directorate, 
but  the  Systems  Change  Requirements  are  developed  by  DSAC  and 
coordinated  with  DLA  Headquarters. 

Both  operational  and  functional  control  of  DSAC  is 
the  r e 8 po ns i b 1 i t y  of  DLA  Headquarers.  Although  the  Supply 
Operations  Directorate  controls  the  design  of  SSR  systems,  the 
Technical  and  Logistics  Services  Directorate  maintains  opera¬ 
tional  control  of  the  operating  elements  at  the  DSCs  that  have 
the  primary  responsibility  for  implementing  the  systems  under 
the  design  control  of  Supply  Operations. 

g.  General  Services  Administration.  Responsibility  for 
the  design,  development  and  implementation  of  automated  systems 
for  logistics  applications  is  resident  at  the  Logistics  Manage¬ 
ment  Division  of  the  Federal  Supply  Service.  Cataloging  and  IMC 
functions  are  automated  at  GSA.  The  automation  of  the  SSR  ap¬ 
plication  was  in  the  conceptual  stage  at  the  time  of  the  DODSSR 
research  at  GSA  and  is  scheduled  for  implementation  in  1°81. 


4 .  Operating  Activities 


a .  General 


Operating  activities  are  those  that  process  SSRs  and 
r  -•  l  .1 1 il  cataloging  transactions.  Figure  II-3  shows  the  relation- 
i  i.jov  :  ..tipal  SSR  operating  activities.  The  SICC  submits 
an  SSR  for  a  supply  support  requirement  to  an  IMM .  Prior  to  sub¬ 
mitting  the  SSR,  the  SICC  is  required  to  determine  if  an  item 
has  an  NSN  and  an  existing  manager  by  screening  cataloging  records 
at  the  Defense  Logistics  Services  Center  (DLSC) .  The  IMM  receives 
the  SSR  and  performs  item  identification  and  screening  actions 
with  DLSC.  If  the  item  is  accepted  for  supply  support,  the  IMM 
advises  the  SSR  submitter  and  performs  cataloging  actions  with 
DLSC.  DLSC  updates  its  records  and  provides  advice  to  both  the 
SICC  and  the  IMM. 

An  operating  activity  may  operate  in  more  than  one 
mode  or  role.  An  activity  in  the  role  of  SICC,  may  submit  an 
SSR  for  a  commodity  oriented  item  to  a  CIMM.  A  SICC  may  also 
submit  an  SSR  to  a  WIMM  for  a  weapons  oriented  consumable  item. 

An  activity  that  is  a  SICC  for  one  item  may  act  as  CIMM  or  a 
WIMM  for  another  item  for  which  it  is  the  IMM. 

OPERATING  ACTIVITIES 


Figure  II-3 


Figure  II-4  matrix  depicts  the  principal  SSR  operat¬ 
ing  activities  for  each  Component  and  indicates  the  various 
operating  modes  for  each  activity. 

b .  Army 

The  five  major  Materiel  Readiness  Commands  (MRCs) 
are  the  principal  submitters  and  receivers  of  SSRs  in  the  Army. 
TARCOM  is  somewhat  unique  in  that  it  is  the  only  Military  Ser¬ 
vice  activity  that  is  a  CIMM.  Some  subordinate  activities  of 
the  MRCs  also  submit  and  receive  SSRs. 

Two  activities  organizationally  placed  under  CERCOM 
submit  and  receive  SSRs.  They  are  the  Electronics  Materiel 
Readiness  Activity  (EMRA)  located  at  Vint  Hill  Farms,  Virginia, 
and  the  Communication  Security  Logistics  Activity  (CSLA)  located 
at  Fort  Huachuca,  Arizona.  The  General  Materiel  and  Petroleum 
Activity  located  at  New  Cumberland  Army  Depot,  Pennsylvania,  and 
the  Army  Support  Activity  at  Philadelphia,  Pennsylvania,  process 
SSRs  as  subordinate  activities  under  TSARCOM.  In  addition,  the 
Army  Medical  Materiel  Agency  submits  SSRs  for  nonmedical  items. 

c.  Navy .  The  two  principal  Inventory  Control  Points 
are  the  submitters  and  receivers  of  SSRs  in  the  Navy.  The  Civil 
Engineer  Support  Office  (CESO)  at  Port  Hueneme,  California,  sub¬ 
mits  support  requirements  to  the  Ships  Parts  Control  Center  (SPCC) 
for  preparation  and  submission  of  SSRs  to  the  appropriate  IMM. 

d.  Air  Force 


The  five  Air  Logistics  Centers  (ALCs)  are  the  major 
processors  of  SSRs  in  the  Air  Force.  The  Air  Force  has  central¬ 
ized  their  cataloging  functions  at  the  Cataloging  and  Standard¬ 
ization  Office  (CASO)  located  at  Battle  Creek,  Michigan.  This 
office  performs  item  identification,  item  entry  control,  stock 
number  submittal  and  other  cataloging  functions  for  the  ALCs. 

CASO  is  assigned  the  direct  supply  support  function 
of  reviewing  SSR  offers  made  to  Air  Force  ALCs  by  IMMs.  This 
includes  item  interchangeability,  substitutability  and  replace- 
ability  technical  assistance. 

e.  Marine  Corps .  The  Marine  Corps  Logistics  Support 
Base  at  Albany,  Georgia,  is  the  only  activity  that  processes 
SSRs  in  the  Marine  Corps.  The  complete  responsibility  for 
systems  design,  development  and  implementation  of  SSR  systems  is 
assigned  to  MCLSBA. 
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PRINCIPAL  SSR  OPERATING  ACTIVITIES 


Figure  II-4 


•  •  Defense  Logistics  Agency 

The  four  Defense  Supply  Centers  shown  in  Figure  II-4 
essentially  operate  in  the  role  of  CIMMs •  Defense  Construction 
and  the  Industrial  Supply  Centers  have  an  additional  role,  albeit 
a  minor  one.  DCSC  provisions  materials  handling  equipment  for 
DLA.  During  this  process,  SSRs  are  prepared  and  forwarded  to 
appropriate  IMMs .  SSRs  for  items  in  the  equipment  for  which 
there  is  no  stock  number,  and  which  will  be  managed  by  DLA  as  a 
WIMM,  are  forwarded  to  DISC  for  processing.  DISC  processes 
these  items  as  a  WIMM  and  performs  the  full  range  of  WIMM  func¬ 
tions  for  these  items. 

As  a  Designated  Special  Function  Activity  (DSFA) , 

DISC  also  receives  and  processes  all  requests  for  cataloging  and 
supply  support  from  DLA  base  supply  activities  for  items  used  in 
base  supply  operations. 

The  Defense  Logistics  Services  Center  performs  the 
following  services  related  to  SSR  functions: 

(1)  Provisioning  Screening; 

(2)  Item  Identification; 

(3)  Stock  Number  Assignment; 

(4)  Item  Management  Coding  and  User  Interest 
Recordation;  and 

(5)  Cataloging. 

These  services  are  provided  for  all  Federal  Components. 

g.  General  Services  Administration.  The  Logistics  Data 
Management  Division  of  the  Federal  Supply  Service  of  GSA  Head¬ 
quarters,  Washington,  D.C.,  is  the  single  focal  point  for  pro¬ 
cessing  of  SSRs  for  GSA  managed  items. 

h.  Coast  Guard.  Three  Coast  Guard  ICPs  are  currently 
submitting  SSRs  under  the  procedures  specified  in  the  IMM  Manual 
effective  1  May  1978.  The  DODSSR  Study  has  no  information  indi¬ 
cating  that  the  Coast  Guard  is  receiving  SSRs  in  a  WIMM  capac¬ 
ity. 

E.  FUNCTIONS 


Historically,  SSR  processing  has  not  been  designated  a  major 
functional  area  of  supply,  but  rather  has  been  considered  a  part 
of  one  or  more  major  functional  areas,  such  as  provisioning  or 
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cataloging.  The  basic  functional  tasks  Involved  In  the  prepara¬ 
tion,  submission,  processing,  and  control  of  SSRs  by  SSR  submit¬ 
ters  and  receivers  are  contained  In  the  IMM  Manual.  These  tasks 
are  performed  in  relation  to  and  support  of  several  functions. 
The  basic  interrelationship  of  these  major  functional  areas  and 
SSR  processing  Is  shovn  in  Figure  11-5. 

The  major  S£"  tasks  performed  by  submitters  and  receivers 
are  listed  below.  Certain  tasks  related  to  functional  areas 
depicted  in  Figure  II-5  are  also  listed.  These  listings  illus¬ 
trate  the  overlap  and  interrelationship  of  SSR  tasks  within  and 
among  the  major  functional  areas. 

FUNCTIONAL  RELATIONSHIP 


Figure  I I- 5 
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SSR  Submitter 


1 .  Supp 
a  . 


(1)  Perform  provisioning  screening  in  accordance 
with  the  DoD  Provisioning  and  Other  Preprocurement  Manual; 

(2)  Determine  the  range  and  depth  of  support  items 
needed  to  meet  supply  support  requirements; 

(3)  Prepare  and  forward  SSRs; 

(4)  Provide  technical  data  with  SSRs  when  required; 

(5)  Process  advice  received  from  IMM  and  review 
offers  of  standard  or  alternate  items  for  acceptability;  and 

(6)  Establish  Internal  controls  and  followup  proce¬ 
dures. 

b .  SSR  Receiver 

(1)  Receive  and  process  SSRs  and  associated  tech¬ 
nical  data; 

(2)  Perform  item  entry  control  (IEC)  to  preclude 
entry  of  duplicate  items  of  supply,  and  provide  offers  of  alter¬ 
nate  or  standard  items  if  appropriate; 

(3)  Provide  notification  of  acceptance  or  rejection 
of  supply  support; 

(4)  Determine  the  range  and  quantity  of  support 
items  to  be  procured  and/or  stocked; 

(5)  Prepare  Federal  Item  Identification  (Fils)  and 
obtains  NSNs;  and 

(6)  Prepare  and  submit  file  maintenance  transac¬ 
tions  to  DLSC  to  accomplish  IMC  and  user  Interest  registration. 

2 .  Provisioning  Functions 

a.  Integrated  logistics  support  plan/ schedule  develop¬ 
ment  ; 

b.  Item  selection  -  source,  maintenance  and  recover¬ 
ability  coding; 
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c.  Method  of  management  determination  -  Item  management 

coding; 

d.  Provisioning  screening; 

e.  Requirements  forecasting;  and 

f.  Program/End  Item  Application  file  maintenance- 
3 .  Technical  Functions 

a.  Item  identification; 

b.  Item  entry  control; 

c.  Technical  data  determination  and  repository; 

d.  Technical  file  maintenance;  and 

e.  Procurement  Item  description. 

4  .  Cataloging  Functions 

a.  Federal  catalog  item  description; 

b.  NSN  assignment; 

c.  User  interest  registration;  and 

d.  Management  data  recording. 

5 .  Inventory  Control  Functions 

a.  Method  of  support  determination  -  AAC  assignment; 

b.  Requirements  determination; 

c.  Requirements  scheduling; 

d.  Inventory  records  maintenance; 

e.  Budgeting;  and 

f .  Funding . 

6 .  Procurement  Functions 

a.  Procurement  item  identifications; 

b.  Supply  source  recognition; 
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c.  Advertisement/solicitation; 


d .  Award ;  and 

e.  Inspection/quality  control. 

All  of  the  above  functions  and  tasks  are  involved  at  one 
time  or  another,  or  impact  on  the  processing  of  SSRs.  The 
interrelationship  of  these  functions  in  terms  of  the  organiza¬ 
tions  responsible  for  these  functions  and  their  impact  on  SSR 
processing  will  be  discussed  in  more  detail  in  Volume  II  of  this 
Report. 

F.  SUMMARY 


The  management  environment  consists  of  the  policies,  proce¬ 
dures,  organizations,  functions,  and  systems  necessary  to 
accomplish  SSR  processing.  The  policies  and  procedures  con¬ 
tained  in  the  IMM  Manual  form  the  basis  for  the  requirement  for 
SSR  processing.  The  functions  that  must  be  performed  and  the 
organizations  required  to  perform  these  functions  generate  the 
requirement  to  design  and  develop  systems  to  accomplish  these 
functions.  The  operating  segment  of  this  environment  exists  at 
those  activities  that  implement  SSR  systems  that  have  been  devel¬ 
oped  and  provided  to  them  to  accomplish  SSR  processing.  Each  of 
the  factors  involved  in  the  management  environment  affect  the 
end  product  of  requesting  and  obtaining  supply  support. 

A  smoothly  operating,  effective  and  efficient  system  is  a 
product  of  the  adequacy  of  each  of  the  factors  in  the  management 
environment.  A  system  results  from  the  interaction  of  policies, 
procedures,  organizations,  and  functions.  There  should  be 
clearly  defined  goals,  a  plan  to  achieve  these  goals  and  a 
method  of  measuring  achievement.  To  the  extent  that  there  are 
clearly  defined  goals,  definitions,  requirements,  and  conven¬ 
tions  to  request  and  obtain  supply  support  in  combination  with 
appropriately  designed  and  Implemented  systems,  supply  support 
will  be  provided  in  an  effective  manner.  To  the  extent  that 
deficiencies  exist  in  one  or  more  of  these  factors,  a  set  of 
problems  is  created  that  will  impair  supply  support. 

The  DODSSR  Study  was  initiated  because  of  problems  that  had 
been  reported  through  the  SPG.  The  types  of  problems  reported 
indicated  potential  defects  in  more  than  one  area  of  the  manage¬ 
ment  environment.  The  study  group  attempted  to  identify  prob¬ 
lems  associated  with  each  of  the  factors  and  management  levels 
associated  with  supply  support  requests.  These  problems  were 
categorized  and  associated  with  one  or  more  areas  of  research 
and  techniques  of  problem  resolution.  Chapter  III  of  this 
Volume  provides  a  description  of  our  problem  identification 
efforts. 


This  Chapter  discussed  the  stnigeaent  environment  in  general 
terms  In  order  to  show  a  general  framework  of  the  policies,  pro¬ 
cedures,  organisations,  functions,  and  systems  for  obtaining 
supply  support*  Chapter  IV  of  Volume  I,  and  Volumes  II  and  III, 
discuss  each  of  these  factors  in  detail  In  relation  to  the  prob¬ 
lems  outlined  in  Chapter  III,  Volume  I.  Finally  Chapter  V  of 
Volume  I  addresses  analysis,  conclusions  and  potential  solutions 
to  these  problems. 


CHAPTER  III 


PROBLEM  IDENTIFICATION 


A.  INTRODUCTION 


The  DODSSR  Study  Team  was  establlshad  to  identify  and  cor¬ 
rect  probleaa  associated  with  systaas  for  generating,  trans¬ 
acting,  controlling  and  aanaglng  Supply  Support  Requests  (SSRs). 
The  study  was  initiated  because  of  probleaa  reported  during 
meetings  of  the  SPG.  The  probleaa  reported  by  the  SPG  include: 

*  Extended  transal ss Iona  tines. 

*  Delinquent  SSRs. 

*  Excessive  nuaber  of  rejects. 

*  Inadequate  controls. 

*  Deficient  aanageaent  reports. 


B.  APPROACH 


The  study  group  viewed  the  probleas  reported  by  the  SPG  as 
Indicators  or  syaptoas  of  deficiencies  or  aalfunctlons  in  the 
systems  for  generating,  transmitting,  controlling  and  aanaglng 
SSRs.  The  basic  approach  was  to  conflra  or  deny  the  original 
problems  reported,  to  further  describe  and  define  these  prob¬ 
lems,  to  ascertain  If  additional  probleas  exist,  and  to  identify 
and  recommend  corrections  to  the  underlying  causes  of  these 
probleas  to  accomplish  the  study  objectives. 

During  the  course  of  the  study,  the  DODSSR  Study  Team  period¬ 
ically  participated  In  meetings  with  the  SPG  and/or  study  con¬ 
tact  points  from  the  Components.  The  study  team  provided  brief¬ 
ings  on  the  progress  of  the  study  and  discussed  the  status  of 
the  study,  Service/ Agency  participation  in  the  study  and  the 
future  course  and  timing  of  the  study.  The  Component  and  study 
team  representatives  exchanged  views  on  SSR  problems  and  dif¬ 
ficulties  being  encountered  by  the  study  group  in  researching 
these  problems  in  order  to  develop  solutions. 

As  a  result  of  these  meetings  the  Component  and  study  repre¬ 
sentatives  agreed  upon  research  techniques  to  supplement  the 
basic  research  being  conducted  of  the  SSR  policies  and  procedures, 
and  the  systems  design  and  implementation  of  SSR  procedures  at 


systems  design  and  operating  activities.  Joint  participation  In 
this  research  by  the  study  group  and  headquarters,  systems  design 
and  operating  level  activities  of  the  Components  was  utilized  to 
the  maximum  extent  possible. 

Three  major  supplemental  research  techniques  were  used  to 
identify,  categorize,  analyze  and  correct  SSR  problems;  ques¬ 
tionnaires,  tests,  and  data  collection  and  analysis.  Each  of 
these  techniques  are  discussed  below. 

C .  QUESTIONNAIRES 

Three  types  of  questionnaires  were  developed,  one  general 
purpose  and  two  special  purpose  questionnaires.  The  general 
purpose  questionnaire  was  an  opinion  survey  of  a  wide  range  of 
possible  problems  and  recommendations.  One  of  the  special  pur¬ 
pose  questionnaires  was  a  validation  analysis  questionnaire  on 
validation  practices  and  the  other  was  a  data  element  question¬ 
naire  concerning  the  organization,  use  and  adequacy  of  SSR  for¬ 
mats  and  data  elements.  Each  of  these  questionnaires  is  dis¬ 
cussed  be  low. 

1 .  Problems/Recommendations  Questionnaire 
a .  Background 

During  study  research  at  headquarters,  systems  design 
and  operating  activities  throughout  tne  course  of  the  study,  the 
study  group  asked  these  activities  to  identify  problems  associated 
with  any  of  the  elements  in  the  management  environment  (policies, 
procedures,  organizations,  functions,  systems)  affecting  the 
generation,  transmission,  processing,  control  or  management  of 
SSRs.  These  activities  were  also  asked  to  provide  recommenda¬ 
tions  to  correct  specific  problems  being  reported  or  systems 
changes  to  improve  SSR  systems  in  general.  Problems  were  also 
identified  and  documented  during  the  course  of  our  policies  and 
procedures  review,  and  the  systems  design  and  operational  imple¬ 
mentation  reviews  at  the  activities  visited. 


In  order  to  insure  the  widest  possible  amount  of 
participation,  the  study  team  requested  the  Component  study  con¬ 
tact  points  to  ask  each  of  their  systems  design  and  operating 
activities  throughout  their  respective  Components  to  document 
and  report  to  the  study  group  those  problems  they  were  experi¬ 
encing  with  the  design  and  Implementation  of  the  new  SSR  Proce¬ 
dures,  and  their  recommendations  for  improvements  to  the  system. 
The  establishment  of  this  problem  reporting  system  expanded  our 
source  of  Information  to  Include  all  major  systems  design  and 
operating  activities,  not  Just  those  that  were  visited  by  the 
study  group. 


During  the  course  of  the  DODSSR  Study,  a  joint  DLA/ 
Air  Force  Inspector  General  (IG)  Team  conducted  a  survey  of 
problems  related  to  SSR  practices  and  procedures  at  DLA  and  Air 
Force  activities.  The  IG  Team  provided  a  copy  of  their  report 
to  the  DODSSR  Study  Team  and  requested  that  problems,  findings 
and  recommendations  contained  in  the  report  be  incorporated  into 
the  DODSSR  Study.  The  study  team  agreed  to  consider  the  IG 
findings  in  the  DoD  study  to  ensure  that  the  problems  and  recom¬ 
mendations  reported,  which  were  based  upon  conditions  obtaining 
at  DLA  and  Air  Force  activities,  were  also  relevant  to  the  opera¬ 
tions  of  other  Government  Components.  Since  some  of  the  IG 
recommendations  had  a  potential  impact  upon  other  Government 
Components,  it  was  felt  that  the  interaction  of  the  other  Service 
activities  with  DLA  and  the  General  Services  Administration  (GSA) 
as  well  as  other  Service  relationships  with  Air  Force  should  be 
cons idered . 

b .  Pur  jse 

(1)  To  identify  and  highlight  potential  problems 
and  recommendations  for  further  analysis  and  consideration. 

(2)  To  provide  a  broad  base  of  participation  in  the 
study  by  users  and  to  take  advantage  of  their  experience  and 
judgment  . 

(3)  To  permit  an  objective  analysis  of  the  problems 
and  comments  on  the  problems  by  an  independent  study  group  in 
consonance  with  other  analyses  being  performed  during  the  course 
of  the  study . 

c .  Methodology 

( 1 )  Development 

The  study  team  established  a  library  of  prob¬ 
lems  and  recommendations  that  had  been  collected  during  the  con¬ 
duct  of  the  study.  Each  item  was  reviewed,  consolidated,  cate¬ 
gorized  and  labeled  prior  to  entry  into  the  library.  Each  entry 
was  labeled  with  its  source,  including  the  type  and  name  of  the 
submitter.  All  submitting  sources  were  recorded  for  each  item. 
Each  item  was  also  identified  by  major  problem  type  and  placed 
into  a  major  problem  category. 

The  questionnaire  was  developed  by  extracting 
items  from  the  problem  library.  Figure  III-l  is  a  representative 
sample  page  from  this  questionnaire.  Items  outside  the  scope  of 
the  study  were  not  included  in  the  questionnaire.  Where  contri¬ 
butions  from  different  submitters  expressed  essentially  the  same 
problem  situation  or  position  on  an  issue,  they  were  consolidated 
into  one  item  in  the  questionnaire.  Contributions  presenting 
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divergent  or  opposite  views  on  the  same  issue  were  included. 

The  source  of1  the  entries  was  not  indicated  on  the  question¬ 
naire.  Each  entry  reflected  the  viewpoint  of  one  or  more  indi¬ 
vidual  submitters  and  was  included  in  the  questionnaire  on  that 
basis.  No  attempt  was  made  by  the  study  group  to  editorialize 
entries  or  to  pass  judgment  in  any  way  on  the  relative  merit  of 
an  item. 

(2)  Organization .  The  problems  and  recommendations 
included  in  the  questionnaire  were  organized  into  five  basic 
categories.  Some  items  may  be  included  in  more  than  one  cate¬ 
gory,  depending  upon  the  orientation  of  the  particular  problem. 

( a )  Policy 

Entries  in  this  category  include  items 
that  relate  to  the  policy  section  of  the  DoD  directives  and 
manuals.  These  are  issues  that  deal  with  the  question  of  what 
should  be  done  and  the  major  criteria  as  to  the  applicability  of 
an  action,  and  whether  or  not  an  action  should  be  performed. 

Examples  of  this  category  include  criteria 
for  submitting  an  SSR,  who  funds  for  quantities  in  SSRs ,  what 
type  of  SSR  should  be  submitted  for  different  types  of  require¬ 
ments. 

( b )  Procedures 

Items  in  this  category  relate  to  the  ques¬ 
tion  of  how  an  event  should  be  accomplished  rather  than  should 
it  be  performed.  This  area  deals  with  the  manner  or  methodology 
in  which  an  action  is  performed.  Items  in  this  category  relate 
to  the  procedures  section  of  the  IMM  Manual. 

Examples  of  items  in  this  category  include 
instructions  on  the  use  of  SSRs,  selection  and  use  of  a  partic¬ 
ular  transaction  or  format,  description  of  data  elements,  the 
application  and  interpretation  of  data  elements,  codes,  and  pro¬ 
cedures  for  the  entry  of  data  in  transactions. 

( c )  Systems 

A  system  is  the  automated  or  manual  plan 
consisting  of  an  organized  grouping  of  processess  to  accomplish 
actions  in  accordance  with  the  policies  and  procedures  specified 
in  the  IMM  Manual.  Entries  in  this  category  deal  with  the  way 
in  which  systems  design  or  operating  activities  interpret  and 
implement  the  SSR  procedures. 
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Examples  Include  differing  interpretations 
In  the  design  and  programming  of  the  SSR  procedures,  and  vari¬ 
ances  in  programs  or  processes  in  the  handling  of  SSR  transac¬ 
tions.'  In  other  words,  the  general  performance  of  actions  In¬ 
volved  in  requesting  and  providing  supply  support. 

(d)  Validation .  Validation  Is  the  procedure 
or  process  used  to  check  the  entry  of  data  In  terms  of  content 
and  format  for  correctness  or  compliance  with  applicable  stan¬ 
dards,  rules  and  conventions.  As  such,  this  category  crosses 
the  lines  of  both  procedures  and  systems.  Problems  in  this 
category  were  shown  separately  because  of  the  emphasis  placed  on 
this  category  throughout  the  study  by  SSR  system  designers  and 
processors.  This  category  relates  directly  to  the  problem  of 
"excessive  number  of  rejects"  reported  by  the  SPG.  Because  of 
this  emphasis  and  the  number  of  entries  received  in  this  cate¬ 
gory,  it  was  considered  a  major  problem  area  by  the  study  group 
and  treated  separately. 

( e )  Data  Elements 


A  data  element  is  a  name  for  a  class  or 
category  of  data  based  on  natural  or  assigned  relationships  that 
can  be  used  to  denote  a  set  of  data  items.  For  example,  the 
data  item  "Tuesday"  is  a  member  of  the  set  denoted  by  the  data 
element  "weekday." 


This  category  is  also  related  to  the  pro¬ 
cedures  and  systems  category,  but  it  is  also  shown  separately 
due  to  the  emphasis  placed  upon  this  item  and  the  frequency  of 
mention.  Because  of  this  emphasis,  this  was  considered  a  major 
problem  area  by  the  atudy  group  and  treated  separately. 

Most  of  the  items  reported  centered  around 
two  data  elements,  Document  Identifier  Codes  (DICs)  and  Action 
Taken  Codes  (ATCs).  These  codes  identify  types  of  SSR  transac¬ 
tions  and  the  various  actions  taken  on  these  transactions. 

( 3 )  Population  Sample 

This  questionnaire  was  sent  to  four  systems 
design  activities  and  18  operating  activities  in  order  to  obtain 
the  broadest  base  of  participation  and  experience  in  the  iden¬ 
tification  and  resolution  of  these  problems.  Service/ Agency 
headquarters  activities  were  also  Invited  to  submit  replies. 

All  replies  were  subf'  •*d  to  the  study  team  for  evaluation. 
Replies  were  received  each  of  the  systems  design  and  operat¬ 

ing  activities. 
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Since  this  was  an  opinion  survey,  each  activ¬ 
ity  was  asked  to  indicate  their  concurrence  or  nonconcurrence 
and  to  provide  any  remarks  to  clarify  their  answer.  Activities 
were  encouraged  to  submit  any  additional  problems  or  recommenda¬ 
tions  which  they  felt  were  significant. 

Generally,  each  activity  responded  to  all  of 
the  questionnaire  items,  either  through  indication  of  concur¬ 
rence,  nonconcurrence  or  remarks. 

d .  Evaluation 

Evaluation  was  performed  by  the  study  group.  Each 
of  the  responses  were  tallied  and  recorded  on  a  master  record. 
Remarks  were  also  recorded  for  consideration  along  with  the 
standard  replies.  Since  this  questionnaire  was  highly  subjec¬ 
tive  in  nature,  no  attempt  was  made  to  use  a  simple  enumeration 
of  the  number  of  concurrences  or  noncurrences  for  each  item.  In 
many  cases  the  explanation  in  the  remarks  block  contained  more 
information  than  an  "X"  in  the  "Concur”  or  "Nonconcur”  columns. 

This  questionnaire  was  used  to  obtain  a  general 
feeling  of  the  incidence  of  problems  and  the  opinion  of  field 
activities  in  regard  to  particular  items.  Obviously  items  with 
a  high  Incidence  of  agreement  of  submitters,  those  that  had  a 
significant  explanatory  statement,  or  that  had  been  confirmed  by 
Independent  research  by  the  study  group  were  tagged  for  addi¬ 
tional  attention. 


Each  of  the  entries  on  the  questionnaire  were  iden¬ 
tified  to  one  or  more  other  analytical  techniques  for  further 
analysis  to  confirm  the  incidence  of  the  item,  to  clarify  and/or 
explain  the  item  and  to  develop  corrections  and/or  changes  to 
eliminate  the  problem  or  Improve  system  processing.  Responses 
to  this  questionnaire  were  considered  in  conjunction  with  the 
policies  and  procedures  review,  systems  design  analysis,  opera¬ 
tional  implementation  review,  data  collection  and  analysis, 
research  tests  and  other  questionnaires  covered  by  Volumes  II 
and  III,  with  the  results  incorporated  into  the  comparative 
analysis  contained  in  Chapter  V  of  this  Volume. 

2 .  Validation  Analysis  Questionnaire 
a .  Background 

One  of  the  most  common  complaints  received  by  the 
study  team  was  the  excessive  number  of  rejects  of  SSRs  by  IMMs . 
This  was  attributed  by  the  respondents  to  differences  in  valida¬ 
tion  concepts  and  criteria  uBed  in  the  automated  SSR  processing 
systems  of  SSR  submitters  and  receivers. 


The  problem  of  "excessive  rejects"  was  originally 
reported  by  the  SPG.  This  was  subsequently  confirmed  by  study 
research  during  visits  to  field  activities  and  by  a  preliminary 
analysis  of  SSR  transactions  obtained  as  a  result  of  a  data 
collection  by  the  study  team. 

The  study  team,  therefore,  decided  to  pursue  a  vig¬ 
orous  analysis  of  validation  systems  used  to  validate  incoming 
and  outgoing  SSRs. 

b.  Purpose .  The  variations  and  limitations  of  systems 
documentation  available  to  the  study  group  inhibited  the  type  of 
in-depth  analysis  desired.  The  study  group  developed  a  standard 
questionnaire  to  obtain  information  from  systems  design  activ¬ 
ities  to  be  used  in  conjunction  with  available  documentation  to 
perform  an  analysis  to  determine  the  compatibility  of  validation 
systems  with  each  other  and  with  conventions  for  entry  of  data 
in  SSR  formats  contained  in  the  SSR  Procedures. 

c .  Methodology 

(1)  Development .  The  validation  analysis  question¬ 
naire  was  designed  to  permit  a  review  of  the  ed i t / va 1 i d a t i o n 
design  concepts,  approach,  methodology,  technique,  structure  and 
criteria  of  the  automated  systems  of  each  of  the  Service/Agencies 
used  to  check  both  incoming  and  outgoing  SSR  transactions,  in¬ 
cluding  request,  advice,  offer,  reply,  followup  and  response 
transactions . 

(2)  Organization  and  Content.  The  questionnaire 
contained  three  sections;  a  set  of  instructions  providing  an 
outline  of  the  coverage  and  the  types  of  information  desired, 
and  two  types  of  forms  to  provide  the  requested  information. 
Examples  of  these  forms  are  shown  in  Figures  III-2  and  III-3. 
Coverage  of  the  questionnaire  is  shown  below. 

(a)  Program  Structure/Hierarchy.  Respondents 
were  requested  to  indicate  whether  separate  validation  programs 
had  been  developed  or  whether  validation  criteria  was  imbedded 
into  other  programs  containing  processing  for  other  actions  in 
addition  to  validation.  Each  program  was  to  be  listed  with  an 
indication  of  the  content  of  that  program  and  sequence  of  run¬ 
ning  of  that  program  in  relation  to  other  processing  actions. 

(b)  Validation  Structure/Hierarchy.  Requested 
information  in  this  category  included  information  on  the  levels 
of  validation  being  performed,  order  of  validation  of  individual 
data  elements  and  the  relative  location,  sequence  and  timing  of 
individual  data  element  validations  in  relation  to  the  level  of 
validation  being  performed  and  interface  with  other  processing 
actions  being  accomplished. 
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DODSSR  STUDY  VALIDATION  ANALYSIS  QUESTIONNAIRE 


Source:  DODSSR  Study  Letter  of  22  November  1978,  Subject:  Validation  Analysis 
Quest  lontia  1  re  • 


DODSSR  STUDY  VALIDATION  ANALYSIS  QUESTIONNAIRE 


angeability 


(c)  Types  of  Validation.  Respondents  were 
requested  to  provide  information  on  the  forms  provided  to  them 
for  each  of  the  types  of  vali  iation  being  performed  and  the 
order  or  sequence  of  validation  between  and  within  a  particular 
type  of  validation.  A  separate  form  was  provided  for  each  of 
the  types  of  validation  shown  below. 

:  Package 

:  Card/Data  Element  Combinations 

:  Control  Data  Elements 

:  Key  Data  Elements 

:  Match/Duplicate  Checks 

:  Detail  Data  Elements 

(d)  Validation  Procedures.  Forms  were  pro¬ 
vided  to  indicate  validation  procedures.  A  separate  form  was 
provided  for  each  type  of  validation.  Submitters  were  requested 
to  Indicate  the  conditions  and/or  data  elements  being  checked, 
specific  validation  criteria  and  type  of  internal  or  external 
error  code  assigned.  The  submitters  were  required  to  submit  a 
form  for  each  of  the  document  identifier  types  specified  in  the 
SSR  Procedures;  to  indicate  how  valid  and  reject  transactions 
were  handled,  including  which  transactions  were  entered  into 
suspense  files;  whether  single  or  multiple  errors  were  produced 
for  each  input  transaction;  and  how  these  errors  were  communi¬ 
cated  to  functional  users. 

(3)  Population  Sample.  Questionnaires  were  sent  to 
the  systems  design  activities  of  the  Army,  Navy,  Air  Force,  DLA 
and  GSA.  It  was  requested  that  the  questionnaires  be  completed 
by  the  lead  and  detail  programmers  for  those  applications  pro¬ 
cessing  and  validating  incoming  and  outgoing  SSRs  to  insure  the 
integrity  and  accuracy  of  the  responses.  Replies  were  received 
from  all  activities. 

d.  Evaluation .  The  validation  questionnaires  were 
reviewed  for  accuracy  and  content.  Like  the  Problems/Recom¬ 
mendations  Questionnaire,  it  was  not  intended  that  these  ques¬ 
tionnaires  would  be  used  by  themselves.  The  intent  was  to  use 
them  in  conjunction  with  a  number  of  other  analysis  techniques, 
and  to  integrate  them  into  the  comparative  analysis  contained  in 
Chapter  V  of  this  Volume.  Some  of  the  uses  of  these  question¬ 
naires  are  indicated  below. 
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(1)  The  results  were  used  In  combination  with  the 
conventions  contained  In  the  SSR  Procedures  to  develop  a  DODSSR 
Edit/Validation  program  to  process  SSR  transactions  received  In 
the  DODSSR  Data  Collection. 

(2)  Analysis  of  the  questionnaires  was  made  in  con¬ 
junction  with  reports  generated  from  the  DODSSR  Validation  Pro¬ 
gram  and  the  statistical  reports  generated  from  the  DODSSR  Data 
Base  as  described  in  the  Performance  Evaluation  in  Volume  III. 

(3)  Results  were  compared  with  the  systems  design 
and  implementation  reviews  described  in  Volume  II. 

(4)  The  Validation  Analysis  Questionnaire  was  com¬ 
pared  with  the  Data  Element  and  Problems/Recommendations  Ques- 

t lonnaires  . 

(5)  Comparison  was  also  made  with  the  Validation 
Test  described  below. 

3 .  Data  Element  Matrices  Questionnaires 


a .  Background 

Another  common  complaint  received  by  the  study  team 
was  that  the  SSR  procedures  and  formats  are  too  complex,  and 
that  there  are  too  many  data  elements  and  codes  within  these 
data  elements.  Users  felt  that  the  complexity  of  the  forms  and 
numerous  unused  data  elements  contributed  to  the  large  number  of 
rejects  and  loss  of  SSRs  being  reported.  The  respondents  recom¬ 
mended  that  the  reported  problems  be  reduced  through  the  simpli¬ 
fication  of  the  procedures  and  forms  and  elimination  of  unused 
data  elements  and  formats. 

These  complaints  relate  directly  to  three  of  the 
five  principal  problems  reported  by  the  SPG;  delinquent  SSRs, 
number  of  rejects  and  inadequate  controls.  Because  of  the 
numerous  complaints  in  this  area,  the  study  team  developed  a 
questionnaire  to  permit  an  analysis  of  SSR  formats  and  data  ele¬ 
ments  based  upon  user  experience. 

b.  Purpose  .  To  determine  what  control  and  detail  data 
elements  in  SSRs  are  being  used,  and  how  they  are  being  used  by 
systems  design  and  operating  activities. 

c .  Methodology 

(1)  Development .  The  data  element  matrices  were  de¬ 
signed  to  determine  the  adequacy  and  use  of  each  of  the  SSR  for¬ 
mats  and  the  data  elements  contained  in  these  formats.  Matrices 
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were  developed  for  each  document  identifier  code  format  contained 
in  the  SSR  Procedures.  A  separate  form  was  developed  for  each 
transaction  type  for  incoming  and  outgoing  provisioning  and  non¬ 
provisioning  SSRs  . 

(2)  Organization  and  Content.  Separate  forms  were 
developed  for  control  and  detail  data  elements.  Control  data 
elements  are  those  that  are  literally  used  to  control  or  exer¬ 
cise  direction  over  the  processing  of  SSRs.  The  control  elements 
are  used  to  sequence  the  SSRs  in  order  to  store  and  retrieve  them 
from  manual  and  automated  files.  They  are  also  used  to  group 
related  transactions  and  to  route  and  control  them  throughout 
the  processing  cycle.  Detail  data  elements  are  those  that  are 
used  throughout  processing  to  accomplish  required  individual 
actions.  For  example,  quantities  used  in  requirements  determina¬ 
tion  to  procure  items  for  support. 

( a )  Control  Data  Element  Matrices 

During  our  research  we  found  that  activ¬ 
ities  were  processing  and  controlling  SSRs  in  different  sequences 
using  the  same  or  different  control  data  elements.  If  such  pro¬ 
cedures  were  significantly  different,  this  could  impact  upon 
communication  between  activities  sending  and  those  receiving 
SSRs. 

Figure  1 11-4  represents  a  sample  page  from 
the  Control  Data  Element  Matrices.  Activities  were  requested  to 
fill  out  the  matrix  provided  by  indicating  the  sequencing  of  the 
SSR  transactions  by  control  data  elements  when  these  transactions 
were  received  and  input  to  processing,  the  sequence  for  valida¬ 
tion,  sequence  when  they  were  sent  to  another  activity  and  the 
sequence  used  for  storing  and  retrieving  these  transactions  in 
suspense  and  history  files.  For  each  of  these  actions,  activi¬ 
ties  were  asked  to  indicate  for  each  control  element  which  was 
used  first,  second,  etc. 

The  same  questionnaire  was  sent  to  systems 
design  and  operating  activities.  Systems  Design  Activities 
(SDAs)  were  asked  to  provide  information  on  automated  processes, 
and  operating  activities  were  asked  to  provide  information  on 
manual  actions . 

( b )  Detail  Data  Element  Matrices 

Numerous  comments  were  received  to  the 
effect  that  there  were  many  data  elements  and  codes  required  by 
the  procedures  but  were  not  needed  to  accomplish  SSR  processing. 
Activities  with  no  use  for  a  particular  element  had  no  real 
incentive  to  take  care  in  providing  the  element  correctly  or 
even  providing  it  at  all. 


DODSSR  Study  Letter  of  9  November  1979,  Subjec 
Questionnaire. 


Because  of  this,  systems  design  activities 
were  asked  to  complete  those  matrices  as  shown  by  the  sample  In 
Figure  III-5.  A  form  was  provided  for  each  of  the  document 
Identifier  types  and  conditions  specified  In  the  SSR  Procedures. 
SDAs  were  requested  to  indicate  for  each  data  element  what  auto¬ 
mated  systems  applications  and  files  used,  which  data  elements, 
and  what  was  the  usage. 

Operating  activities  were  asked  to  complete 
the  matrices  shown  by  the  sample  In  Figure  III-6.  Instead  of 
designating  computer  system  usage,  they  were  asked  to  Indicate 
whether  the  data  element  was  being  used,  Its  specific  use  and 
the  responsible  organizational  element  that  was  the  principal 
user  of  the  data  element. 

(3)  Population  Sample.  The  control  and  detail  data 
elements  questionnaires  were  sent  to  four  systems  design  and  18 
operating  activities.  This  is  the  same  population  used  for  the 
Problems/ Recommends tions  Questionnaire.  This  is  also  the  same 
population  used  for  our  data  collection  and  analysis,  to  ensure 
compatibility  of  analyses  and  the  broadest  possible  degree  of 
coverage,  participation  and  interrelation. 

d .  Evaluation 

The  questionnaires  were  reviewed  for  completeness, 
clarity  and  compatibility  of  entries  from  form  to  form  within 
submitting  activity,  and  among  submitting  activities  of  the  same 
and  different  Components.  Clarifications  were  requested  and 
obtained  from  individual  submitters  as  required. 

Like  the  Pr o b 1 ems /Re corame nda t i ons  and  Validation 
Analysis  Questionnaires,  the  Data  Elements  Questionnaires  were 
analyzed  in  conjunction  with  all  the  other  study  techniques. 

These  questionnaires  were  somewhat  subjective  in  nature  and  were 
used  as  indicators  of  potential  significant  information  to  be 
considered  with  other  supporting  analyses,  and  confirmed  or 
denied  on  the  basis  of  objective  analysis. 

D.  TESTS 


Tests  are  trials  or  experiments  that  are  performed  to  show 
how  an  existing  system  is  performing  or  whether  a  proposed  new 
system  is  feasible.  The  test  applies  a  standard  set  of  proce¬ 
dures  to  specific  input  under  controlled  conditions.  The  result 
is  then  examined  to  determine  the  relative  performance  of  the 
test.  The  experiment  may  be  performed  under  actual  or  simulated 
operational  conditions.  Two  tests  were  conducted  during  the 
DODSSR  Study.  These  tests  are  described  below. 


1.  Validation  Test 


a.  Purpose .  The  validation  test  was  run  to  perform  a 
comparative  analysis  of  the  ed i t / va 1 i d a t i o n  criteria  used  by  the 
automated  systems  of  the  Army,  Navy,  Air  Force  and  DLA. 

b .  Procedures 


Several  structured  sample  decks  of  punched  cards 
were  prepared  by  the  study  group.  Some  decks  represented  out¬ 
going  SSRs  and  other  decks  represented  incoming  SSRs.  Decks 
were  also  prepared  for  CIMM  and  WIMM  type  items.  Cards  were 
prepared  for  each  of  the  types  of  transactions  contained  in  the 
SSK  Procedures.  The  card  decks  contained  valid  data  elements 
and  preselected  error  conditions. 

The  test  decks  were  run  through  the  actual  computer 
programs  that  had  been  designed  by  the  Component  systems  design 
activities.  Although  the  actual  programs  were  used,  this  was  a 
simulation  of  actual  operating  conditions  using  the  actual  pro¬ 
grams,  but  with  simulated  transactions  and  test  files  operating 
in  the  test  mode. 


Test  activities  were  requested  to  provide  copies  of 
outputs  from  the  test  runs  to  the  study  group  for  analysis. 
Output  test  products  provided  for  evaluation  included  copies  of 
reports,  listing  of  output  transactions  and  copies  of  SSR  master 
or  suspense  file  listings  of  transactions  posted  to  these  files 
as  a  result  of  the  validation  runs. 

c.  Population  Sample.  The  test  decks  were  mailed  to 
the  test  activities  for  running  in  accordance  with  the  proce¬ 
dures  contained  in  the  covering  letter  (DODSSR  Study  letters  of 
12  January  1979,  Subject:  Sample  Validation  Runs  for  DODSSR 

Study).  The  test  decks  used  and  test  activities  selected  are 
shown  in  Figure  II  1-7.  There  were  approximately  100  to  200 
records  in  each  of  the  test  decks. 

VALIDATION  TEST  SAMPLE 


Test  Decks 


Outgoing  C I  MM  SSRs 
Outgoing  WIMM  SSRs 
Incomi n  g  C I M  M  SSRs 
I  nc  o m i n  g  W I  MM  SSRs 


Test  Activities 


ALMS  A 

FMSO 

| 

X  i 

X 

I 

X 

X 

X 

X 

X 

X 

DC  S  C 


X 


Figure  III-7 
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d.  Evaluation.  The  validation  test  was  evaluated  in 
conjunction  wi  t  li  the  Validation  Analysis  Questionnaire,  DODSSR 
Validation  Program  results,  Quantitative  Evaluation  statistics 
and  the  field  research  performed  by  the  DODSSR  Study  Team.  The 
results  of  this  evaluation  are  included  in  the  Ed i t / V a  1 i d a t i o n 
Analysis  in  Volume  III  of  this  Report. 

2 .  AUTODIN/Telef ax  Test 

a.  Purpose .  This  test  was  conducted  to  determine  the 
feasibility  of  electrically  transmitting  SSRs  and  related  tech¬ 
nical  data  in  place  of  forwarding  by  U.S.  mail. 

b.  Reference  .  Volume  III  of  the  DODSSR  Report  contains 
a  complete  description  of  the  purpose,  background,  objectives, 
test  procedures  and  evaluation.  A  brief  summary  is  provided 
here  to  show  the  reason  for  the  conduct  of  the  test  and  a  synop¬ 
sis  of  how  it  was  conducted  to  show  the  relationship  of  this 
analytical  technique  with  others  described  in  this  Chapter. 
Please  refer  to  Volume  III  for  a  more  complete  explanation. 

c .  Summary  . 

This  test  is  directly  related  to  the  SSR  transmis¬ 
sion  time,  control  and  delinquency  problems  reported  by  the  SPG. 
The  DODSSR  Study  Team  was  asked  by  the  SPG  to  determine  the 
feasibility  of  transmitting  SSRs  over  AUTODIN.  The  study  team 
had  no  direct  information  on  which  to  make  such  a  determination. 
Permission  was  requested  to  conduct  a  feasibility  test.  The 
Chairman  of  the  SPG  granted  approval  of  the  test  after  repre¬ 
sentatives  of  the  Army,  Navy,  Air  Force  and  DLA  agreed  to  par¬ 
ticipate  in  the  test. 

All  CIMM  SSR  transactions  from  three  Service  SICCs 
to  a  DLA  IMM  were  transmitted  by  AUTODIN  during  the  period 
1  September  through  December  1978.  The  IMM  returned  all  advice 
transactions  to  the  submitters  by  AUTODIN.  Copies  of  all  these 
transactions  were  provided  to  the  DODSSR  Study  Team  in  the  data 
collection  described  below  and  in  Volume  III  of  this  Report. 

During  the  period  1  October  to  31  December  1978  two 
of  the  SICCs  electrically  transmitted  technical  data  using  a 
fasclraile  transmission  system  that  had  been  installed  specifi¬ 
cally  for  the  test.  This  was  a  one-way  transmission  of  tech¬ 
nical  data  from  the  SICC  to  the  IMM.  The  technical  data  was 
marked  with  control  information  to  permit  matchup  with  the  SSRs 
that  had  been  transmitted  by  AUTODIN. 
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Participating  activities  were  provided  with  an  eval¬ 
uation  plan  by  the  DODSSR.  Study  Team  to  evaluate  the  effects  of 
the  test  on  their  operations,  since  this  was  a  live  test  using 
actual  SSR  transactions.  The  activities  were  asked  to  compare 
the  results  of  SSRs  and  technical  data  forwarded  electrically 
with  those  that  were  submitted  by  mail. 

The  study  team  received  copies  of  all  SSRs  submitted 
by  AUTODIN  in  the  data  collection.  These  transactions  were 
placed  in  the  data  base  along  with  other  transactions  collected 
over  an  eight  months  period.  Analytical  reports  were  developed 
to  measure  the  performance  of  the  test  in  terms  of  study  and 
test  objectives.  The  evaluations  submitted  by  the  participating 
activities  were  analyzed  in  combination  with  the  computer  reports 
generated  from  the  quantitative  evaluation  described  in  Volume 
III.  The  complete  description  of  the  conduct  of  test  and  the 
test  results  are  contained  in  Volume  III. 

E .  QUANTITATIVE  EVALUATION 

1.  Background  .  It  was  alleged  by  the  SPG  that  SSRs  were 
not  being  processed  in  a  timely  manner  due  to  an  excessive  reject 
rate,  extended  transmission  times,  a  high  delinquency  rate  and 
inadequate  controls.  The  SPG  had  requested  the  Components  to 
provide  statistical  information  on  the  processing  of  SSRs.  The 
information  provided  by  the  Components  was  limited  and  not  suf¬ 
ficient  to  permit  an  analysis  or  comparison.  The  study  team 
performed  a  review  of  the  management  reports  available  at  head¬ 
quarters,  systems  design  and  operating  activities  of  the  Compo¬ 
nents.  The  team  confirmed  the  SPG  finding  that  there  was  very 
little  management  data  available  on  SSRs  at  any  level  and  that 
available  information  was  not  adequate  to  perform  a  quantitative 
evaluation  of  the  performance  of  the  SSR  Systems.  The  study 
team,  therefore,  asked  for  and  received  permission  from  the  SPG 
to  conduct  a  data  collection  and  analysis. 

2.  Reference .  A  data  collection  and  analysis  was  estab¬ 
lished  as  described  in  Volume  III.  A  brief  summary  is  provided 
here  to  show  the  relationship  of  this  analytical  technique  with 
the  others  described  in  this  Chapter. 

3 .  Summary 

The  collection  and  analysis  of  data  was  originally 
established  because  of  the  lack  of  available  management  reports 
to  provide  even  a  basic  statistical  picture  of  the  system. 

During  the  development  of  the  evaluation  plan,  it  was  enlarged 
to  support  the  other  analytical  techniques  described  here  in 
combination  with  an  overall  measurement  and  analysis  of  the  per¬ 
formance  of  the  SSR  systems  in  support  of  the  study  objectives. 
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A  Quantitative  Evaluation  Plan  was  developed.  A  data 
collection  system  was  established  to  collect  actual  SSR  transac¬ 
tions  from  the  major  SSR  submitters  and  receivers  in  DoD  and 
GSA.  A  computerized  data  base  with  eight  months  of  transactions 
was  established.  Analytical  models  of  the  SSR  systems,  evalua¬ 
tion  criteria,  and  computer  specifications  and  programs  for 
descriptive  and  analytical  reports  were  developed  to  evaluate 
these  systems  • 

The  results  of  this  analysis  is  described  in  Volume  III. 
The  quantitative  evaluation  contained  in  Volume  III  in  conjunc¬ 
tion  with  the  results  of  all  other  study  analyses  is  included  in 
the  comparative  analysis  in  Chapter  V  of  Volume  I  which  forms 
the  basis  for  study  conclusions  and  results. 
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CHAPTER  IV 


SYSTEMS  REQUIREMENT 


A.  FUNCTIONAL  REQUIREMENT 

I .  Introduction 


The  functional  requirement  for  supply  support  requests 
(SSRs)  derives  from  the  need  to  support  end  items  of  equipment 
as  discussed  in  the  supply  support  concept  in  Chapter  II.  The 
SSR  Procedures  contained  in  the  IMM  Manual  form  the  basis  of  the 
functional  requirements  statement  which  is  used  to  design  systemt 
to  generate,  transmit,  process  and  control  SSRs.  The  SSR  Proce¬ 
dures  provide  a  set  of  conventions  consisting  of  card  formats, 
data  elements  and  definitions,  and  codification  instructions  for 
mandatory,  conditional  or  optional  entry  of  data  into  card  for¬ 
mats,  and  procedures  for  generating,  transmitting,  processing 
and  controlling  SSRs. 

The  SSR  Procedures  were  used  by  the  Components  to  design 
their  automated  data  processing  systems.  The  card  formats  con¬ 
tained  in  the  SSR  Procedures  represent  the  various  types  of 
transactions,  events  or  actions  that  can  occur  during  the  SSR 
process.  The  SSR  transactions  have  been  categorized  into  their 
major  types  and  an  explanation  of  each  transaction  type  with  a 
definition  of  key  data  elements  is  provided  to  present  an  under¬ 
standing  of  the  SSR  process.  These  transactions  represent  the 
Inputs  to  and  outputs  from  the  SSR  System.  Through  the  use  of 
document  Identifier  and  transaction  codes  an  SSR  submitter  may 
request  that  an  action  be  taken  or  an  SSR  receiver  may  communi¬ 
cate  an  action  that  has  been  taken  upon  a  request. 

2.  Authority .  The  IMM  Manual  is  published  under  the  author¬ 
ity  of  Department  of  Defense  Directive  4140.26,  Integrated  Man¬ 
agement  of  Consumable  Items. 

3.  Definition .  The  SSR  Procedures  define  an  SSR  as  "A 
request  submitted  by  a  SICC  to  the  CIMM  or  WIMM  which  manages, 
or  i s  the  potential  manager,  of  the  item  or  materiel  required. 

For  items  requiring  Item  Management  Coding,  the  SSR  is  used  as 
an  IMC  card." 

4 .  Purpose 

a.  General  ■  Chapter  I  of  the  IMM  Manual  provides 
general  guidance  applicable  to  Item  Management  Coding,  Logistic 
Reassignment  and  Supply  Support  Requests.  The  stated  purpose  or 
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objective  is  to  eliminate  duplication  of  effort  in  the  wholesale 
materiel  management  of  consumable  items  through  the  application 
of  approved  IMC  criteria  and  the  utilization  of  uniform  proce¬ 
dures  . 


b.  Specific.  The  IMM  Manual  does  not  list  a  specific 
purpose  or  objective  for  SSRs ,  other  than  that  CIMMs  will  pro¬ 
cess  SSRs  and  provide  timely  support.  However,  a  review  of  the 
permissible  transactions  and  procedures  specified  indicate  that 
the  SSR  is  intended  to  accomplish  the  following  actions: 

(1)  Item  Management  Coding  (IMC).  The  SSR  acts  as 
an  IMC  card  when  the  submitting  Component  has  not  previously 
coded  the  item  for  integrated  materiel  management.  The  IMM  is 
charged  with  the  responsibility  of  acting  as  the  Item  Management 
Classification  Agent  and  providing  cataloging  and  supply  support 
for  items  under  the  cognizance  of  the  IMM. 

(2)  Registration  of  User  Interest.  The  aaK  is  used 
to  request  the  addition  of  an  activity  as  a  user  of  an  item  when 
that  activity  has  not  been  previously  recorded  in  the  records  of 
the  IMM  and  DLSC,  and  for  which  support  has  not  been  previously 
provided . 


(3)  Request  for  Supply  Support.  The  requesting 
activity  provides  a  forecast  of  retail  and  replenishment  quan¬ 
tities  to  support  its  requirements  for  the  support  item  being 
requested  to  the  IMM  to  determine  the  method  and  level  of  sup¬ 
port  to  be  provided.  Method  of  support  includes  the  method  of 
management  by  the  IMM  such  as  centrally  stocked,  or  centrally 
procured  but  not  stocked;  and  level  of  support  Includes  the 
quantity  of  materiel  to  be  procured  and/or  stocked  to  support 
the  supply  support  request. 

(4)  Cataloging  Support.  The  SSR  provides  manage¬ 
ment  and  technical  data  to  be  used  by  the  IMM  to  perform  the 
following  actions: 

(a)  Item  Identification.  This  is  the  descrip¬ 
tion  of  the  item  in  relation  to  other  items  of  supply. 

(b)  Item  Entry  Control  (IEC).  Determination 
of  whether  the  item  already  exists  in  the  system  or  if  there  is 
a  suitable  substitute. 

(c)  MSN  Assignment .  IMM  requests  DLSC  to 
assign  an  NSN  for  new  items  of  supply  for  which  integrated 
materiel  management  is  assumed. 
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(d)  Catalog  Management  Data.  IMM  updates  the 
management  data  segment  of  DLSC  flies  to  record  such  data  as 
unit  price,  unit  of  issue,  etc. 

5  .  Scope 

a  .  Inclusions 

(1)  C  ganl za  t ions .  Provisions  of  the  IMM  Manual 
apply  to  the  Army,  Navy,  Air  Force,  Marine  Corps,  Defense  Logis¬ 
tics  Agency,  Defense  Nuclear  Agency,  National  Security  Agency, 
General  Services  Administration  and  Civil  Agencies  of  the  Federal 
Government . 

(2)  Items  .  The  SSR  Procedures  apply  to  consumable 
type  items  subject  to  item  management  assignment  to  an  IMM,  in¬ 
cluding: 

(a)  Provisioning  and  non pr o v i s ion i n g  items. 

(b)  CIMM/WIMM  Items. 

(c)  Items  already  managed  by  an  IMM. 

(d)  New  items  being  assigned  to  an  IMM  for  the 

first  time. 


(e)  Initial  and  follow-on  supply  support 


requi rements 


b.  Exc lusions  .  The  SSR  Procedures  are  not  applicable 
to  the  following  categories  of  items. 

(1)  Medical  Material. 

(2)  Clothing  and  Textiles. 

(3)  Subsistence  Items. 

(4)  Fuels. 

( 5 )  Amrnuni t ion . 

(6)  Items  that  meet  the  IMC  criteria  for  Service 


retention 


(7)  Items  peculiar  to  use  by  a  foreign  country 
and  not  used  by  U.S.  Forces. 

(8)  Nonconsumable  items. 

6.  Generation  Criteria.  The  SSR  Procedures  are  rather  per¬ 
missive  in  nature  and  do  not  provide  specific  criteria  as  to 
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when  an  SSR  should  or  should  not  be  generated.  Generation  of 
SSRs  is  at  the  discretion  of  the  submitter.  Procedures  are  more 
specific  as  to  when  an  SSR  Is  not  required  than  when  an  SSR  is 
required . 

a.  SSRs  are  not  required  for  existing  IMM  items  with 
NSNs  unless  there  are: 

(1)  Five  or  more  of  the  same  systems/equipments  to 
be  supported. 

(2)  Items  are  essential  to  support  of  high  priority 

systems. 

(3)  Items  have  a  production  leadtime  of  six  months 

or  more. 


b.  SSR  changes  resulting  from  design  or  program  changes 
are  not  required  after  24  months  have  elapsed  since  the  original 
Date  of  Request  (DOR)  for  the  original  item  being  supported. 

New  support  requirements  resulting  from  changes  after  24  months 
will  be  submitted  as  new  requirements.  Changes  affecting  less 
than  10  percent  of  the  original  requirements  need  not  be  sub¬ 
mitted. 


c.  SSRs  will  not  be  submitted  for  locally  managed  items 
unless  the  SICC  is  recommending  that  the  IMM  change  the  method 
of  management  from  local  to  central  management. 

SSR  Transaction  Types.  SSR  transactions  are  required  to 
be  prepared  in  punched  card  formats.  There  are  three  basic  types 
of  SSR  transactions;  one  card  provides  program  data,  another  is 
a  request  for  support  for  a  particular  item,  and  the  third  is  an 
advice  card  to  request  or  provide  status  of  processing  of  a 
supply  support  request.  A  three  position  Document  Identifier 
Code  (DIC)  is  used  to  distinguish  these  transactions.  Each 
transaction  type  and  subtype  represents  a  particular  action  or 
event  as  outlined  below. 

a •  PDSSR  (Program  Data  Supply  Support  Request) 

A  PDSSR  transaction  is  a  header  card  that  provides 
program  data  and  accompanies  individual  supply  support  requests 
for  separate  line  items  of  supply.  PDSSRs  are  identified  by  DIC 
CWA  or  WWA.  The  first  position  identifies  whether  the  request 
is  for  a  CIMM  or  a  WIMM  item;  C  for  CIMM  and  W  for  WIMM. 

The  PDSSR  is  designed  for  SICCs  to  furnish  initial 
and  supplementary  provisioning  or  other  program  data  concerning 
the  end  item  for  which  supply  support  is  being  requested.  Pro¬ 
gram  data  includes  the  following  type  of  information: 
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End  Item  Identification 


:  Date  NSNs  Required 

:  Date  Repair  Parts  Required 

:  Weapons  System  Identification 

:  End  Item  Delivery  Schedule 

A  one-position  Type  of  Change  Code  (TCC)  is  used  to 
identify  provisioning  and  nonprovisioning  actions.  This  code 
also  indicates  whether  the  program  data  being  supplied  is  an 
original  submission  of  program  data  or  whether  it  is  a  design  or 
program  change  to  an  original  submission  of  a  provisioning 
package . 


b.  LISSR  (Line  Item  Supply  Support  Request).  The  LISSR 
is  forwarded  from  a  SICC  to  an  IMM  to  provide  management,  tech¬ 
nical,  catalog,  and  quantitative  data  to  request  cataloging  and 
supply  support  action  for  a  specific  item  of  support.  There  are 
two  basic  types  of  LISSRs;  requests  for  support  for  individual 
line  items  and  transactions  providing  technical  and  cataloging 
data  associated  with  a  request. 

(1)  Request  Transactions.  The  DIC  is  also  used  to 
identify  the  type  of  request  being  forwarded.  Requests  fall 
into  three  categories;  NSN  items.  Part  Number  items  and  PSCN 
items.  The  first  position  of  the  DIC  indicates  whether  the 
request  is  for  a  CIMM  or  WIMM  item.  The  second  position  “X" 
indicates  that  it  is  a  line  item  transaction  and  the  third  posi¬ 
tion  indicates  the  type  of  item  being  requested  as  shown  below. 
The  TCC  is  also  used  to  indicate  whether  the  request  is  ah  orig¬ 
inal  submission,  change  or  cancellation  of  an  original  sub¬ 
mission. 


(a)  NSN .  A  CXA  or  WXA  transaction  indicates 
that  the  request  is  for  an  item  with  an  existing  stock  number. 
The  item  is  classified  as  a  Condition  1  item  if  the  NSN  item  is 
currently  managed  by  an  IMM.  If  there  is  no  current  DoD  Manager 
assigned,  the  item  is  classified  as  a  Condition  2  item. 

(b)  Part  Number .  A  Part  Number  item  is  iden¬ 
tified  by  DIC,  WXB  or  CXB.  This  item  has  no  recorded  NSN  for  it 
in  DLSC  files  and  is  classified  as  a  Condition  3  item. 

(c)  PSCN .  This  item  has  a  Permanent  System 
Control  Number  assigned  in  the  DLSC  files.  It  is  classified  as 
a  Condition  2  item  and  is  identified  by  DIC  WXC  or  CXC. 
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(2)  Catalog  Transactions.  Catalog  transactions  may 
accompany  a  request  transaction  to  provide  additional  technical 
or  catalog  type  data.  There  are  three  types  of  catalog  transac¬ 
tions. 


( a )  Item  Name  .  A  DIC  C  X  F  identifies  a  trans¬ 
action  providing  a  noun  name  for  an  item.  A  noun  name  must  be 
furnished  for  a  part  number  item  if  technical  data  is  not  pro¬ 
vided  with  the  part  number  request.  Technical  data  is  required 
for  part  number  item  requests  sent  to  CIMMs .  If  technical  data 
cannot  be  supplied  for  any  reason  the  item  name  card  must  be 
forwarded  to  provide  the  minimum  identification  information 
required  to  obtain  a  stock  number  for  the  item. 

(b)  Additional  Reference  Number.  A  CXG  trans¬ 
action  provides  an  additional  reference  number  (part  number) 
which  Identifies  the  same  item  of  production  or  supply  as  the 
primary  manufacturer's  part  number  or  NSN  indicated  in  the  asso¬ 
ciated  Re quest  Transaction.  More  than  one  additional  reference 
number  card  may  be  submitted  for  a  LISSR  transaction. 

(c)  Additional  Multi-Service  User.  A  CXK 
transaction  identifies  additional  users  who  are  claimants  on 
Multi-Service  Contracts  and  have  requirements  for  supply  support 
for  the  item  being  provisioned. 

c  .  LIAC  (Line  Item  Advice  Card).  LIACs  are  used  by 
both  SSR  submitters  and  receivers  to  reflect  actions  taken  on  a 
request  transaction.  There  are  four  basic  types  of  LIAC  trans¬ 
actions. 

(1)  CXI  Advice  (IMM  to  SICC).  CXI  Advice  Transac¬ 
tions  reflect  the  results  of  IMM  processing  on  a  request  trans¬ 
action  by  a  SICC.  Each  advice  transaction  has  a  transaction 
code  called  an  Action  Taken  Code  (ATC)  that  indicates  the  type 
of  action  taken  on  a  request.  There  are  approximately  70  dif¬ 
ferent  ATCs  to  indicate  the  type  of  action  taken  on  an  SSR. 

These  transaction  codes  can  be  grouped  into  four  major  advice 
categories . 


(a)  Accept  .  Accept  advice  indicates  that  the 
request  for  supply  support  has  been  accepted,  and  support  will 
be  provided.  This  transaction  may  provide  a  new  support  date 
and  provide  information  as  to  how  the  item  will  be  supported. 

(b)  Offer  .  The  IMM  may  offer  a  different 
item  as  a  substitute  or  replacement  Item  for  the  one  that  was 
requested  in  the  original  SSR.  The  submitter  of  the  SSR  is  re¬ 
quired  to  review  the  offered  item  and  advise  the  IMM  of  Its 
acceptability. 
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(c)  Status .  The  IMM  may  provide  status  on  a 
request  when  action  on  a  transaction  has  not  been  completed. 
Status  may  also  be  provided  in  response  to  a  followup  from  the 
submitter  for  advice  on  a  request. 

(d)  Reject .  An  SSR  may  be  rejected  by  an  IMM 
for  a  number  of  reasons.  Although  there  are  numerous  ATCs  that 
can  be  used  to  identify  a  specific  reject  reason,  reject  codes 
can  be  grouped  into  several  major  categories.  An  item  may  be 
rejected  because  it  has  been  improperly  classified  in  the  incor¬ 
rect  FSC  (Federal  Supply  Class)  or  forwarded  to  the  incorrect 
manager.  An  invalid  NSN  or  PSCN  may  have  been  indicated.  Im¬ 
proper  or  inadequate  catalog  or  technical  data  is  also  cause  for 
rejection  of  an  SSR.  If  data  has  been  incorrectly  entered  into 
a  card  format,  the  transaction  may  fail  validation  routines  and 
be  returned  to  the  submitter.  A  transaction  may  also  be  rejected 
if  it  is  a  duplicate  transaction,  if  the  transaction  fails  to 
match  a  corresponding  transaction  in  control  files  or  if  the 
item  cannot  be  procured  by  the  IMM. 

(2)  CX2  Replies  to  Offers  (SICC  to  IMM).  When  a 
Submitter  receives  an  offer  of  an  alternate  or  substitute  item 
from  an  IMM  the  submitter  must  review  the  offer  and  advise  as  to 
its  acceptability.  The  SSR  submitter  has  the  alternatives  of 
accepting  the  offer,  rejecting  the  offer  or  cancelling  the  orig¬ 
inal  req  ue s  t  . 

(3)  CX3  Followup  Transaction  (SICC  to  IMM).  If 

a  SICC  has  submitted  an  SSR  and  has  not  received  an  answer  from 
an  IMM,  a  followup  may  be  forwarded  to  obtain  status  on  the 
original  request.  A  followup  may  be  sent  for  three  different 
reasons  • 

(a)  Initial  Advice.  A  followup  may  be  sent 
if  the  SICC  has  not  received  any  type  of  advice  on  a  previous 
request  . 

(b)  Final  Advice  .  If  initial  advice  has  been 
received,  but  notification  of  final  action  taken  has  not  been 
received  a  followup  may  be  sent  to  obtain  final  disposition  on 
an  SSR . 

(c)  NSN.  If  an  SSR  has  be  submitted  for  a 
part  numbered  item  and  an  acceptance  has  -e  .  'ceived,  a  follow¬ 
up  may  be  sent  to  obtain  a  stock  number  .  th.  '.tem. 


(4)  CX4  Response  to  Followup  (IMM  to  SICC).  A  CX4 
transaction  provides  a  response  from  an  IMM  to  a  followup  trans¬ 
action  from  a  SICC.  Only  two  types  of  response  are  provided  for 


in  the  SSR  Procedures.  If  status  has  been  recorded  in  the  con¬ 
trol  files  of  the  IMM,  the  status  that  is  recorded  in  the  file 
will  be  provided;  otherwise,  advice  will  be  provided  indicating 
that  there  is  no  record  of  a  previous  request  in  the  file. 

8.  Transmission  of  SSRs.  The  SSR  Procedures  currently  pro¬ 
vide  that  ail  PDSSR  and  LISSR  transactions  and  associated  tech¬ 
nical  data  will  be  mailed  to  the  IMM  responsible  for  management 
of  items  for  which  support  is  being  requested.  The  procedures 
permit,  but  do  not  require,  all  LIAC  transactions  to  be  sub¬ 
mitted  over  the  Automatic  Digital  Network  (AUTODIN). 

9 .  Controls 


a.  Provlslonlng/SSR  Packages.  Historically  the  provi¬ 
sioning  of  end  items  of  equipment  has  been  accomplished  on  a 
package  basis.  A  package  consists  of  groups  of  items  that  are 
handled  together.  There  are  a  number  of  different  types  of 
packages  as  shown  in  Figure  IV-1 .  Each  of  these  packages  have 
certain  data  elements  assigned  that  are  considered  Control  Data 
Elements  or  Control  Keys  that  are  used  to  identify  a  particular 
package  and  are  used  to  monitor  the  package  during  its  pro¬ 
cessing  cycle. 


TYPES  OF  PROVISIONING/SSR  PACKAGES 


Type 

Definition 

Control  Keys 

Provi sioning 

All  items  on  Provisioning 

PCC 

L  i  s  t  (  s  ) 

PDSSR 

Items  submitted  to  same 

PCC,  Activity 

IMM  from  same  SICC 

Codes,  DOR 

LISSR 

Transactions  for  same  item 

PCC,  Activity 

of  supply 

Codes,  ISN,  DOR 

Figure  IV-1 

(1)  Provisioning  Package.  A  provisioning  package 
consists  of  all  items  on  a  provisioning  list  for  a  particular 
end  item  or  Component.  A  Provisioning  Control  Code  (PCC)  is 
assigned  to  identify  and  control  a  particular  provisioning  pro¬ 
ject  through  the  provisioning  processing  phase. 

(2)  PDSSR  Package.  A  PDSSR  package  includes  all 
supply  support  request  transactions  submitted  to  the  same  IMM 
from  the  same  SICC.  The  controlling  data  elements  are  the  PCC, 
Activity  Codes  for  the  submitting  and  receiving  activities,  and 
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Dace  of  Request.  This  Is  referred  Co  as  a  PDSSR  Package  because 
the  package  includes  a  PDSSR  as  a  header  card  with  all  the  asso¬ 
ciated  LISSRs  (Requests  and  Catalog  Cards)  forwarded  to  an  IMM 
with  the  same  date  of  request. 

(3)  LISSR  Package.  A  line  item  package  consists  of 
all  the  transactions  for  the  same  item  of  support  submitted  to 
the  same  IMM  from  the  same  SICC.  A  LISSR  Package  submitted  to 
an  IMM  includes  the  request  transaction  and  all  the  associated 
catalog  and  technical  information  cards  with  the  same  PCC, 
Activity  Codes,  and  DOR  for  the  same  Item  Serial  Number  (ISN). 

An  ISN  is  a  six-charac ter  Item  Serial  Number  assigned  to  a  LISSR 
Package.  It  is  used  for  sequential  line  item  and  communication 
control  to  relate  all  line  item  cards  in  a  request  for  the  same 
item  of  support.  This  serial  number  is  required  to  be  used  in 
all  subsequent  actions;  changes,  followups,  advice,  offers,  and 
responses  pertaining  to  the  same  line  item  under  the  same  PCC. 

b.  Control  Elements.  There  are  eight  different  control 
data  elements  that  are  used  to  sequence  and  control  SSR  transac¬ 
tions  for  processing,  and  to  store  and  retrieve  SSR  transactions 
in  files.  These  control  elements  are  also  used  to  relate  all 
the  different  types  of  SSR  transactions  to  each  other  and  to 
maintain  an  audit  trail  from  initial  request  to  completion  of  an 
SSR.  Each  of  the  individual  control  data  elements  listed  below 
may  be  used  in  various  combinations  to  identify  individual  SSR 
transactions  or  packages  of  SSRs . 

ACF:  Activity  Code  From 

ACT:  Activity  Code  To 

PCC:  Provisioning  Control  Code 

ISN:  Item  Serial  Number 

DOR:  Date  of  Request 

DOA:  Date  of  Advice 

TCC:  Type  of  Change  Code 

DIC:  Document  Identifier  Code 

c.  Technical  Data  ■  SICCs  are  required  to  establish 
appropriate  internal  control  and  followup  procedures  to  assure 
that  technical  data  which  was  not  available  at  the  time  of  sub¬ 
mission  of  SSRs  is  submitted  to  CIMMs  at  the  time  this  data 
becomes  available. 

d.  Suspense  Files  .  IMMs  are  required  to  maintain  a 
suspense  record  of  request  and  advice  actions  until  120  days 
have  elapsed  since  final  advice  was  provided  to  the  SICC.  This 
file  will  be  used  to  respond  to  followup  transactions  by  pro¬ 
viding  status  from  the  file  or  to  indicate  that  there  is  no 
record  of  a  request  if  there  is  no  record  in  the  file. 
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10.  Performance  Evaluation 


a.  Goals  .  The  IMM  Manual  does  not  provide  any  specific 
goals  for  the  accomplishment  of  SSR  processing.  There  are  two 
general  requirements  mentioned  in  the  manual  for  SICCs  and  IMMs . 

(1)  SICCs  are  required  to  provide  SSRs  to  IMMs  as 
soon  as  possible  after  determination  of  the  range  and  quantity 
of  supply  support  requirements. 

(2)  IMMs  are  required  to  furnish  support  items  in  a 
timely  manner  to  fill  SICCs  supply  support  requirements. 

b.  Standards .  There  are  a  number  of  timeframes  in  the 
SSR  Procedures  for  the  accomplishment  of  actions  based  upon  the 
submission  or  receipt  of  various  SSR  transactions.  The  major 
timeframes  are  listed  below: 

:  Initial  Advice  -  Provide  within  25  days  of  receipt 

SSR . 

:  NSN  Advice  -  Provide  NSN  by  need  date,  but 

not  later  than  60  days  after 
SSR  receipt . 

:  Reply  to  Offer  -  Required  within  60  days  from 

date  of  offer. 

-  35  days  from  date  of  submission 
of  request  for  initial  advice. 

-  70  days  from  date  of  submission 
of  request  for  NSN. 

-  70  days  from  date  of  submission 
of  reply  to  offer  for  NSN. 

-  IMM  provide  response  to  follow¬ 
up  within  15  days  of  receipt  of 
f  o 1 lowup . 

c.  Management  Reports.  The  IMM  Manual  does  not  require 
the  production  of  any  management  reports  to  measure  SSR  processing 
and  to  evaluate  the  performance  of  the  SSR  process. 

1 1 .  Summary 

This  section  described  the  requirements  for  generation, 
transmission,  processing,  control  and  management  of  SSRs  on  a 
functional  basis.  The  functional  requirement  is  specified  in 
the  SSR  Procedures  in  the  IMM  Manual.  The  SSR  Procedures  pro¬ 
vide  a  set  of  rules,  conventions  and  mechanized  formats  to  be 
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us-'d  by  SICCs  and  IMMs  In  requesting  and  providing  supply  sup¬ 
per  for  items  subject  to  integrated  materiel  management  assign¬ 
ments.  The  procedures  provide  a  method  of  c ommu n i c a t i o n  to 
accomplish  SSR  processing,  but  do  not  constitute  a  system,  in 
and  of  themselves,  to  accomplish  that  processing. 

The  SSR  Procedures  provide  a  description  of  standard 
inputs,  and  outputs  to  be  used,  and  functional  processes  to  be 
accomplished.  These  procedures  provide  the  basis  for  the  design 
and  development  of  automated  or  manual  systems  to  be  used  by 
SICCs  and  ltd  Ms  to  process  SSRs.  The  next  section  will  describe 
a  conceptual  system  of  the  type  required  to  be  developed  to 
implement  the  functional  requirement  as  outlined  in  the  IMM 
Ma  nua 1  . 

B  .  CONCEPTUAL  SYSTEM 

1.  Purpose  .  The  purpose  of  presenting  a  Conceptual  System 
is  to  depict  the  type  of  system  required  to  provide  supply  sup¬ 
port  in  accordance  with  the  supply  support  concept  described  in 
Chapter  II  and  to  implement  the  functional  requirements  as  dis¬ 
cussed  in  Paragraph  A.  of  this  Chapter.  A  conceptual  system  is 
one  which  provides  an  abstract  representation  of  the  primary 
functions  to  be  accomplished  and  the  relationship  of  these  func¬ 
tions  to  each  other.  The  major  phases  and  events  are  discussed 
in  the  preferred  sequence  in  which  they  are  performed  in  rela¬ 
tion  to  the  major  organizational  entity  responsible  for  each 
major  functional  area. 

2  .  Conceptual  Systems  Model 

Figure  IV-2  illustrates  a  model  of  the  required  concep¬ 
tual  system  in  terms  of  Inputs,  processing  actions  and  output 
products.  The  model  takes  the  form  of  a  flow  chart  representing 
the  supply  support  cycle  commencing  with  initial  provisioning 
actions  and  ending  with  final  supply  support  results. 

Major  events  have  been  combined  into  processing  phases 
or  segments  of  the  supply  support  cycle.  Each  phase  should  be 
accomplished  in  the  order  specified  reading  from  left  to  right. 

A  phase  consists  of  a  grouping  of  events  that  are  functionally 
and  time  related.  Each  event  should  take  place  in  the  top  to 
bottom  sequence  shown  within  each  processing  phase.  In  addition 
to  being  functionally  and  time  related,  events  within  a  pro¬ 
cessing  phase  are  organizationally  related  in  that  each  phase  is 
performed  by  a  major  organizational  entity,  such  as  a  contrac¬ 
tor,  Provisioning  Activity,  Service  Item  Control  Center  or  Inte¬ 
grated  Materiel  Manager.  Individual  events  may  be  performed  by 
different  organ  I za t i onal  elements  from  activity  to  activity; 
however,  events  that  are  more  closely  functionally  related  are 
usually  performed  by  the  same  organizational  element. 
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Figure  IV-: 


Events  shown  by  a  solid  line  should  generally  be  per¬ 
formed  in  the  position  of  the  processing  flow  as  shown.  Events 
shown  by  dashes  may  be  performed  in  different  phases  as  shown  in 
the  processing  flow.  Also,  an  event  shown  by  dashes  may  be  per¬ 
formed  more  than  once  during  the  cycling  of  the  system.  Each 
phase  must  be  accomplished  in  a  time  sequential  order;  however, 
some  of  the  events  are  not  critical  to  the  accomplishment  of  a 
particular  processing  segment  and  thus  may  be  performed  later. 
Timing  and  performance  of  an  event  is  also  effected  by  system 
design  and  implementation  variances  among  the  Components.  This 
is  more  clearly  explained  in  the  description  of  the  conceptual 
systems  model  below. 

3 .  Description  of  Major  Phases  and  Events 


The  supply  support  cycle  consists  of  five  major  pro¬ 
cessing  phases;  therefore,  the  conceptual  system  model  reflects 
five  principal  processing  segments.  The  cycle  begins  with  the 
preparation  and  submission  of  provisioning  documentation  by  the 
contractor;  followed  by  receipt  and  processing  of  the  contrac¬ 
tor's  documentation  by  the  provisoning  activity;  generation  and 
transmission  of  support  requirements  by  the  Service  Item  Control 
Center  to  the  I MM;  processing  of  the  supply  support  requests  by 
the  IMM,  who  in  turn  provides  advice  to  the  SSU  submitter  to 
complete  the  cycle.  This  cycle  may  iterate  several  times  before 
actions  are  complete  on  individual  transactions  or  groups  of 
supply  support  requests. 

Each  of  the  major  phases  and  events  are  described  below 
keyed  to  the  order  of  appearance  in  the  chart  in  Figure  IV-2. 

a.  Contractor  Processing.  The  end  item  contractor  per¬ 
forms  those  actions  and  provides  that  information  as  specified 
in  the  basic  contract  and  specifications  referenced  by  the  con¬ 
tract  on  which  the  end  items  are  procured.  There  are  two  key 
events  related  to  the  supply  support  of  items  of  supply  contained 
in  the  equipment. 

(1)  DLSC  Screening.  This  event  is  performed  if  it 
is  a  contractually  required  item.  Procedures  vary  among  and 
within  Services  on  the  requirement  to  screen  part  numbers  against 
the  catalog  files  of  the  Defense  Logistics  Services  Center  to 
determine  if  NSNs  are  assigned  to  one  or  more  support  items  in 
an  equipment.  Within  a  Service,  contractor  screening  may  be 
required  for  procurement  of  one  equipment  but  not  for  another. 
Stock  numbers  picked  up  during  the  screening  process  are  pro¬ 
vided  to  the  provisioning  activity  and  become  part  of  the  provi¬ 
sioning  technical  documentation  supplied  under  the  end  item 
contract. 
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( 2 )  Provisioning  Technical  Documentation  (PTD)  . 

The  contractual  requirement  for  provisioning  documentation  is 
specified  by  the  Provisioning  Requirements  Statement,  DD  Form 
1949-2,  PTD  Data  Selection  Sheet,  DD  Form  1949-1,  and  the  Con¬ 
tractor  Data  Requirements  List,  DD  Form  1432.  Provisioning 
documentation  is  prepared  in  accordance  with  Military  Standards 
1552  (Appendix  F,  Reference  22)  and  1561  (Appendix  D,  Reference 
23).  This  documentation  identifies  support  items  contained  in 
the  equipment  and  is  used  by  the  provisioning  activity  to  deter¬ 
mine  initial  requirements  and  cataloging  of  items  to  be  sup¬ 
ported  during  the  provisioning  process.  Provisioning  technical 
documentation  consisting  of  provisioning  lists  of  items  con¬ 
tained  in  the  equipment  and  associated  technical  data,  such  as 
drawings,  sketches  and  item  descriptions  may  be  provided  to  the 
provisioning  activity  in  a  variety  of  media  as  shown  on  the 
chart.  This  information  may  be  in  the  form  of  hard  copy,  machine 
processable  magnetic  tapes  or  punched  cards,  and/or  microform. 

b.  Provisioning  Processing.  Provisioning  is  the  man¬ 
agement  process  for  determining  and  acquiring  the  number  and 
quantity  of  different  support  items  required  to  operate  and 
maintain  an  end  item  for  an  initial  period  of  service.  During 
the  provisioning  process,  the  Military  Services  determine  items 
required  to  support  the  equipment  and  the  method  of  support  for 
these  items.  There  are  six  major  events  to  accomplish  the  pro¬ 
visioning  process  as  a  prerequisite  to  generating  supply  support 
requests  . 

(1)  Catalog  Data  Screening.  When  the  provisioning 
technical  data  is  received,  the  data  is  reviewed  for  adequacy. 
Depending  on  whether  the  contractor  performed  screening  with 
DLSC  and  the  types  of  catalog  files  maintained  by  a  given  Compo¬ 
nent,  either  local  or  DLSC  screening,  or  both,  should  be  per¬ 
formed  to  obtain  NSNs  for  part  numbered  items  and  verify  sub¬ 
mitted  NSNs,  and  obtain  management  data  and  user  interest  infor¬ 
mation.  The  results  of  this  screening  along  with  the  rest  of 
the  provisioning  data  is  passed  to  the  next  event. 

(2)  File  Establishment.  Program  data  on  the  end 
item  of  equipment  and  item  data  on  support  items  in  the  equip¬ 
ment  is  entered  into  provi soning  files  after  the  data  has  been 
verified  and  screened.  Establishment  of  this  data  in  the  files 
may  be  performed  prior  to  or  in  combination  with  the  succeeding 
events  shown  below. 

(3)  SM&R  Coding.  Source,  Maintenance  and  Recover¬ 
ability  Codes  are  assigned  to  all  support  items  to  convey  main¬ 
tenance  and  supply  instructions  to  the  various  logistic  support 
levels  and  using  commands.  They  are  assigned  based  on  the 
logistic  support  planned  for  the  end  item  and  its  components. 
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The  uniform  code  format  as  specified  in  the  Joint  Regulation 
governing  the  use  and  application  of  SM&R  Codes  (Appendix  F, 
Reference  20)  is  composed  of  three  two-character  parts.  Source 
Codes,  Maintenance  Codes  and  Recoverability  Codes  in  that  order. 
This  is  the  first  step  in  the  item  selection  process  and  deter¬ 
mines  which  items  (range)  will  be  supported  and  how  they  will  be 
supported  (manufacture,  purchase  or  repair). 

(4)  Item  Management  Coding  (IMC).  Item  Management 
Codes  are  applied  in  accordance  with  the  criteria  in  the  IMM 
Manual.  This  process  indicates  whether  the  item  will  be  managed 
as  a  consumable,  reparable  or  end  item,  and  whether  the  item 
will  be  managed  as  a  CIMM,  WIMM  or  Lead  Service  Item.  Items, 
that  are  not  retained  by  the  provisioning  activity  for  manage¬ 
ment  are  candidates  for  supply  support  requests  for  CIMM  or  WIMM 
management  if  they  are  consumable,  or  for  Nonconsumable  Item 
Materiel  Support  Requests  (NIMSRs)  if  they  are  nonconsumable. 

(5)  File  Maintenance.  After  initial  entry  of  pro¬ 
gram  and  item  data  for  an  end  item  into  provisioning  files  this 
data  is  continually  updated  during  the  provisioning  process. 
Codification  actions  such  SM&R  and  IMC  are  recorded  in  the 
files.  Some  Components  also  provide  for  indication  of  the  sta¬ 
tus  of  supply  support  on  provisioned  items.  Information  on  both, 
retained  items  and  those  for  which  support  is  requested  from 
another  manager,  may  be  recorded  in  the  file  to  track  the  sup¬ 
port  condition  of  the  equipment  to  determine  if  the  equipment  is 
ready  to  be  placed  into  an  operational  mode. 

(6)  Requirements  Determination.  The  determination 
of  the  quantitative  requirements  for  initial  and  replenishment 
support  may  be  performed  during  the  provisioning  process  or  may 
be  performed  during  the  SICC  SSR  processing  phase  based  upon 
factors  developed  during  provisioning.  At  this  time  SSR  can¬ 
didates  for  consumable  CIMM  and  WIMM  Items  are  generated.  When 
this  event  Is  performed  here,  actual  quantities  will  be  entered 
into  the  SSR  candidate.  If  actual  computation  of  quantities  is 
not  performed  here  factors  should  be  provided  in  the  candidate 
SSR  or  placed  in  provisioning  files  for  later  processing  during 
the  SICC  SSR  processing  phase.  The  SSR  candidates  that  are 
generated  are  passed  to  the  SICC  SSR  processing  phase  for  further 
processing.  Consumable  or  reparable  Items  that  are  retained  for 
management  by  the  provisioning  activity  and  reparable  items 
managed  by  another  Service  are  not  covered  by  the  IMM  Manual  and 
are  not  within  the  immediate  boundary  of  the  DODSSR  Study  and; 
therefore,  are  not  discussed  further  in  the  Conceptual  Systems 
Model.  This  is  discussed  under  the  supply  support  concept  in 
Chapter  II  of  this  Volume. 
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c.  SICC  SSR  Processing.  The  Service  Item  Control  Cen¬ 
ter  SSR  processing  is  shown  as  a  separate  phase  to  highlight 
those  events  more  closely  related  to  the  actual  generation  and 
submission  of  the  SSR.  This  manner  of  presentation  also  permits 
the  consideration  of  those  SSRs  that  are  generated  from  other 
than  the  provisioning  process  called  nonprovisioning  SSRs.  In 
addition,  the  creation  of  provisioning  SSRs  generally  should 
occur  toward  the  end  of  provisioning  processing  or  during  a 
separate  SSR  processing  phase. 

(1)  Catalog  Data  Screening.  The  SSR  candidates 
that  are  received  for  processing  may  be  screened  against  local 
or  DLSC  files  if  this  action  has  not  been  accomplished  during 
contractor  or  provisioning  processing  phases.  The  SSR  Proce¬ 
dures  in  the  IMM  Manual  require  that  items  submitted  in  SSRs  be 
screened  in  accordance  with  the  procedures  contained  in  the 
Screening  Manual,  DoD  4100. 38M  (Appendix  D,  Reference  24).  When 
this  event  is  performed  during  this  processing  phase,  it  may  be 
performed  before  or  after  validation  as  described  below. 

(2)  Edit/Validation.  This  is  the  process  whereby 
data  elements  in  a  transaction  are  checked  both  as  to  content 
and  format  to  see  if  they  are  entered  in  accordance  with  pre¬ 
scribed  conventions.  The  SSR  procedures  provide  specific  rules 
and  criteria  for  entry  or  nonentry  of  data  in  SSR  transactions. 
If  data  is  not  entered  in  accordance  with  the  SSR  procedures, 
the  transactions  may  be  rejected  by  the  IMM  in  accordance  with 
the  procedures  specified  by  the  manual.  This  process,  there¬ 
fore,  should  be  performed  to  preclude  rejection  by  the  IMM. 

(3)  Requirements  Determination.  This  event  will  be 
accomplished  here  if  it  has  not  already  been  performed  during  a 
prior  phase.  If  quantities  are  present  in  the  SSR  candidate,  an 
SSR  may  be  generated  using  these  quantities.  If  factors  are 
present  instead  of  quantities,  quantities  will  be  computed  based 
upon  the  factors. 

(4)  File  Maintenance.  Suspense  and  history  files 
will  be  maintained  on  items  for  which  SSRs  are  generated.  These 
files  will  be  updated  to  record  the  forwarding  of  an  SSR  and 
associated  technical  data  to  an  IMM,  to  record  items  that  have 
been  rejected  during  validation,  and  to  initiate  followups  on 
outgoing  SSRs  and  rejected  candidates.  As  a  result  of  file 
maintenance  or  surveillance,  followups  may  be  generated  for 
corrections  to  internal  rejections  or  for  advice  on  overdue 
SSRs  that  have  been  forwarded  to  an  IMM.  Output  of  any  of  the 
transactions  shown  for  SICC  SSR  processing  may  be  in  manual  or 
mechanized  form.  Outgoing  SSRs  and  followups  must  be  in  punched 
card  format  in  accordance  with  the  SSR  Procedures  in  the  IMM 
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Manual;  however,  the  SSR  Procedures  currently  specify  that  SSRs 
must  be  forwarded  by  mail  while  followups  may,  but  are  not 
required  to  be  forwarded  by  AUTODIN  (Automatic  Digital  Network). 

d.  IMM  SSR  Processing.  Supply  support  requests  and 
associated  technical  data  are  received  by  mail.  Followups  and 
offer  replies  may  be  received  by  mail  or  AUTODIN.  Each  of  the 
events  shown  in  the  IMM  SSR  processing  phase  should  be  performed 
to  satisfy  the  functional  requirements  as  outlined  in  the  IMM 
Manual.  However,  these  events  may  be  performed  at  various  times 
in  various  sequences  and  within  various  organizational  Components 
within  the  IMM  activity. 

(1)  Edit/Validation.  This  event  should  be  per¬ 
formed  first.  Data  elements  should  be  checked  for  format  and 
content  in  accordance  with  SSR  conventions  for  entry  of  data. 

If  a  transaction  fails  the  validation  routine  and  cannot  be  cor¬ 
rected  through  the  edit  function,  it  will  be  rejected  to  the 
SICC  submitter  by  mail  or  AUTODIN.  Transactions  that  pass  vali¬ 
dation  will  be  forwarded  to  the  next  event. 

(2)  Catalog  Data  Screening.  Catalog  data  screening 
should  be  performed  here  even  if  it  has  been  performed  during 
either  the  provisioning  or  SICC  SSR  processing  phases.  Items 
may  be  screened  against  either  local  or  DLSC  files,  or  both. 

Based  upon  the  data  received  from  this  action,  an  SSR  may  be 
accepted,  rejected  and/or  passed  on  the  the  next  event. 

(3)  Method/Level  of  Support.  This  process  deter¬ 
mines  whether  the  item  will  be  centrally  stocked  and  issued, 
centrally  procured  but  not  stocked  or  locally  managed.  Deter¬ 
minations  also  will  be  made  as  to  whether  the  item  will  be  clas¬ 
sified  as  a  demand  based  item,  insurance  item  or  numeric  stockage 
objective  item.  As  a  result  of  this  event,  Acquisition  Advice 
Codes  (AACs)  will  be  assigned.  These  codes  are  identified  in 

the  DIDS  Manual,  DoD  4140. 39M  (Appendix  D,  Reference  25). 

(4)  Requirements  Determination.  Items  designated 
for  central  procurement  and  stockage  will  be  reviewed  to  deter¬ 
mine  if  existing  stocks  are  adequate  or  stock  is  required  for 
new  items.  An  asset  availability  check  will  be  performed  and  a 
procurement  generated  if  a  requirement  exists.  This  event 
should  be  accomplished  before  the  advice  decision  is  made  and 
forwarded  to  the  SSR  submitter. 

(5)  File  Maintenance.  Transactions  that  are  re¬ 
ceived  from  and  forwarded  to  the  SICC  activity  will  be  recorded 
in  the  suspense  and/or  history  files.  These  are  the  control 
files  that  contain  the  disposition  of  SSR  transactions.  Trans¬ 
actions  that  are  output  for  internal  action  and  the  internal 
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Inputs  to  the  system  should  also  be  recorded  in  these  files. 
These  files  serve  to  provide  an  audit  trail  of  inputs  to  and 
outputs  from  this  processing  phase.  Output  transactions  may 
also  be  generated  as  a  by-product  of  file  maintenance. 

(6)  Advice  Decision.  This  event  will  be  performed 
based  upon  the  results  of  the  other  events  in  this  processing 
phase.  Each  of  the  outputs  from  this  processing  phase  as  shown 
on  the  chart  represent  the  general  types  of  advice  that  are  pro¬ 
vided  to  the  SSR  submitter  to  indicate  the  results  of  the  pro¬ 
cessing  of  the  SSR  submitted  by  the  SICC  activity.  The  advice 
will  be  recorded  in  su s p ens e /hi s t or y  files  and  forwarded  to  the 
SSR  submitter  by  mail  or  AUTODIN. 

(7)  Catalog  Actions.  The  IMM  is  responsible  for 
performing  cataloging  actions  for  items  assigned  to  him.  This 
includes  identification  and  description  of  the  item,  requesting 
NSNs,  recording  manager  and  user  interest  on  the  item,  and 
recording  item  technical  and  management  data  in  catalog  files. 

e.  SICC  SSR  Advice  Processing.  This  phase  is  performed 
to  process  and  record  advice  from  the  IMM  and  generally  closes 
out  the  cycle  for  a  given  SSR  transaction.  If  the  advice  re¬ 
ceived  is  an  offer  or  reject;  an  acceptance  or  rejection  of  an 
offer  will  be  forwarded;  or  a  new  SSR  will  be  submitted  for  a 
rejected  transaction.  Acceptance  of  the  offer  closes  out  the 
cycle  while  resubmission  of  an  SSR  creates  a  new  cycle.  Resub¬ 
missions  should  be  processed  by  the  IMM  much  like  an  initial 
SSR. 

(1)  File  Maintenance.  The  advice  received  from  the 
IMM  will  be  recorded  in  the  applicable  files.  Offers  and  rejec¬ 
tions  should  be  reviewed.  The  file  should  be  updated  to  reflect 
the  results  from  the  review  and  outputs  generated  to  reply  to 
offers  and  resubmit  SSRs  . 

(2)  Advice  Review.  Advice  actions  involving  offers 
of  substitute  or  alternate  items  and  rejections  of  SSR  submis¬ 
sions  should  be  subjected  to  local  review.  The  results  of  this 
review  will  be  used  to  update  the  history  of  the  item  and  to 
generate  replies  to  offers  and  resubmission  of  SSRs. 

(3)  Notification  Actions.  This  event  provides  sup¬ 
port  determinations and/or status received  from  the  IMM  to  up¬ 
date  provisioning,  SSR  and/or  cataloging  functions  for  action 
and/or  information. 
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4 .  Summary 


The  conceptual  systems  model  depicts  an  overview  of  the 
functional  requirements  to  provide  supply  support.  This  model 
provides  a  conceptual  basis  for  the  design  and  implementation  of 
systems  to  implement  the  functional  requirements  as  outlined  in 
Paragraph  A.  of  this  Chapter.  The  processing  phases  and  events 
are  shown  in  a  representative  order  and  chronology,  and  depict 
the  relationship  of  phases  and  events  in  the  supply  support 
cycle  . 


This  model  was  presented  here  to  provide  the  reader  with 
an  understanding  of  how  supply  support  requests  are  processed 
and  how  systems  are  developed  to  accomplish  such  processing. 

The  model  does  not  represent  any  automated  or  manual  system 
existing  at  any  Government  Component. 

Volume  II,  Part  1,  covers  the  design  of  automated  sys¬ 
tems  by  Systems  Design  Activities  of  the  Government  Components 
to  implement  SSR  functional  requirements.  The  systems  model 
shown  here  provides  a  basis  for  understanding  the  ADP  systems 
design  charts  and  narrative  depicting  the  actual  systems  de¬ 
signed  by  the  Components.  lach  of  the  phases  and  events  shown 
can  be  accomplished  by  either  an  automated  or  manual  system  or  a 
combination  of  both.  The  systems  design  activity  makes  the 
determination  on  how  to  automate  particular  phases  or  events. 

The  SDA  may  decide  to  combine  phases  into  one  particular  sub¬ 
system  or  application  or  to  prepare  a  stand-alone  application  to 
interface  with  an  existing  application  or  subsystem,  since  the 
existence  of  a  current  system  for  any  of  the  processing  phases 
may  influence  the  design  concepts  for  other  phases.  The  SDA 
also  determines  the  program  stream  to  accomplish  the  processing 
events  within  each  of  the  major  phases  and  the  type,  use  and 
placement  of  computer  files. 

The  conceptual  systems  chart  shown  here  may  also  be  used 
to  understand  and  compare  the  systems  that  were  actually  imple¬ 
mented  by  each  of  the  Government  Components,  as  described  in 
Volume  II,  Part  2,  with  the  functional  requirement  and  the  sys¬ 
tems  design  based  upon  the  functional  requirement  described  in 
this  Chapter.  This  will  permit  a  better  understanding  of  the 
design  and  implementation  philosophies  of  each  of  the  Components 
in  relation  to  the  functional  requirement  and  to  the  design  con¬ 
cepts  of  each  other. 
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CHAPTER  V 


COMPARATIVE  ANALYSIS 
Part  1  -  SYSTEMS 


A.  INTRODUCTION 

The  DODSSR  Study  was  established  to  research,  analyze  and 
resolve  specific  problem  areas  reported  by  the  Components  to  the 
Special  Projects  Group  (SPG)  for  provisioning.  The  specific 
problem  areas  included: 

*  Extended  Transmission  Times 

*  Delinquent  SSRs 

*  Excess  Number  of  Rejects 

*  Inadequate  Controls 

*  Deficient  Management  Reports 

The  management  environment  from  which  these  problem  areas  stem 
was  discussed  in  terms  of  the  applicable  policies  and  procedures 
governing  the  generation  and  processing  of  SSRs  contained  in  the 
IMM  Manual  Implemented  1  May  1978.  The  Components  developed 
systems  to  implement  the  policies  and  procedures  in  the  IMM 
Manual  using  this  manual  as  the  functional  requirements  state¬ 
ment.  The  study  team,  using  the  IMM  Manual,  developed  a  Concep¬ 
tual  Systems  Model  as  a  basis  for  discussion  of  each  Component's 
systems  design  and  operational  implementation  of  this  functional 
requirement.  The  automated  systems  design  and  functional/opera¬ 
tional  implementation  are  presented  on  a  Component  by  Component 
basis  in  Volume  II  of  this  Report.  To  analyze  the  effects  of 
each  Component's  system  design  and  implementation  upon  each  other 
Component's  system  design  and  implementation;  live  data  was 
collected,  certain  tests  were  conducted,  and  descriptive  and 
analytical  reports  were  generated  and  discussed  in  Vol  >me  III. 

The  discussions  In  Volumes  II  and  III  confirmed  the  existence  of 
the  specific  problem  areas  listed  above  and  pointed  out  additional 
problem  areas.  The  Component  implementation  of  the  IMM  Manual 
did  not  in  itself  resolve  any  problem  areas,  but  seemed  to  create 
additional  problems  and  intensify  those  that  already  existed. 
Volumes  II  and  III  illustrate  that  the  IMM  Manual  as  written  is 
not  suitable  for  use  as  a  functional  requirement  for  the  develop¬ 
ment  of  systems.  This  Chapter  brings  together  the  management 
environment,  the  systems  design  and  implementation,  and  the  per¬ 
formance  analysis  into  a  single  comparative  analysis  to  point 
out  the  inconsistencies,  variability  of  interpretation,  and  lack 
of  specific  policies  and  procedures  within  the  IMM  Manual.  This 
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Chapter  also  presents  conclusions  relating  to  the  resolution  of 
the  specific  problem  areas  encountered  in  current  policies,  pro¬ 
cedures  and  systems  for  generation  and  processing  of  SSRs  . 

Part  1  of  this  Chapter  uses  a  total  systems  approach  to  syn¬ 
thesize  the  discussions  of  Volume  II  and  Volume  III  into  current 
system  problem  resolutions  and  a  system  redesign  to  eliminate 
the  specific  problem  areas  mentioned  above.  The  systems  approach 
used  is  centered  around  the  elements  from  the  Conceptual  Systems 
Chart.  Each  processing  phase  within  this  Chart  is  addressed  in 
terms  of  inputs,  files,  processing  of  major  events,  outputs  and 
controls.  Due  to  the  manner  of  processing  and  volumes  of  trans¬ 
actions;  nonprovisioning  SSR  processing,  SSR  changes  resulting 
from  Design  Change  Notices  (DCNs),  joint  provisioning  actions, 
and  NIMSR  processing  are  presented  in  separate  subsections.  The 
final  section  of  Part  1  is  a  summary  analysis  which  discusses 
system  concepts  and  major  events  in  multiple  processing  phases. 

B.  CONTRACTOR  PROCESSING  PHASE 


Processing  leading  to  SSR  generation  begins  when  a  contract 
with  provisioning  requirements  has  been  negotiated  and  agreed 
upon  by  the  end  item  contractor  and  the  Government. 

1.  Inputs.  This  contractual  agreement  serves  as  the  basic 
input  to  the  contractor  processing  phase.  It  defines  the  Pro¬ 
visioning  Technical  Documentation  (PTD)  requirements  and  any 
other  provisioning  related  requirements;  such  as,  provisioning 
screening  to  be  accomplished  by  the  contractor.  The  basis  for 
Provisioning  Technical  Documentation  required  by  DoD  is  contained 
in  MIL-STD- 1552  (Appendix  D,  Reference  22)  and  in  MIL-STD-1561 
(Appendix  D,  Reference  23).  These  Military  Standards  allow  PTD 
to  be  submitted  in  either  hard  copy,  card  or  tape  medium  and 
specifies  the  format  and  data  elements  required.  Many  of  these 
data  elements  eventually  appear  in  SSR  transactions  as  entered 

in  this  PTD. 

2.  Files •  Files  maintained  by  the  contractor  may  be  used 

to  generate  provisioning  lists  which  in  turn  are  used  to  generate 
SSRs. 

3.  Processing .  The  Conceptual  System  Model  (Figure  V-l) 
shows  the  two  major  events  occurring  in  the  contractor  processing 
phase.  These  major  events  include: 

*  DLSC  Provisioning  Screening 

*  Preparation  of  Provisioning  Technical  Documentation 

a.  DLSC  Provisioning  Screening.  Generally  the  Air 
Force  and  Marine  Corps  include  DLSC  provisioning  screening  as  a 
contractual  requirement.  When  the  contractor  is  required  to 
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perform  DLSC  screening,  he  screens  part  numbers  which  he  recom¬ 
mends  be  source  coded  in  the  'P'  (Procured)  series.  These  items 
are  usually  screened  using  a  Type  'F'  screening  transaction  which 
provides  all  exact  and  partial  matches  found  in  DLSC  files.  The 
contractor  generally  uses  a  priority  of  '4'  (the  lowest  avail¬ 
able)  due  to  the  volume  of  items  being  screened.  Screening 
results  are  not  usually  processed  by  the  contractor,  but  are 
either  included  as  part  of  the  PTD  or  in  many  cases  the  screen¬ 
ing  results  are  forwarded  directly  to  the  provisioning  activity 
by  DLSC. 


b.  Prepare  PTD.  The  contractor  is  responsible  for  the 
preparation  and  submittal  of  PTD  as  defined  in  the  contractual 
agreement.  The  contractor  is  not  released  from  this  obligation 
until  the  PTD  has  been  received,  reviewed  and  accepted  by  the 
provisioning  activity.  Generally  the  minimum  PTD  submitted  by 
contractors  includes  a  hard  copy  Provisioning  Parts  List  and 
associated  drawings,  aperture  cards,  and  catalog  references. 

4.  Outputs .  Provisioning  screening  transactions  may  be 
output  on  tape  and  transmitted  via  AUTODIN  for  processing  or  the 
tape  may  be  mailed  to  DLSC  for  processing  when  the  volume  is 
high.  PTD  may  be  in  hard  copy,  EAM  card,  magnetic  tape,  or  a 
combination  of  these  media. 

5.  Controls  .  The  contractual  agreement  Including  data 
requirements  and  the  provisioning  performance  schedule  serves  as 
the  primary  control  in  this  processing  phase  and  contains  the 
requirements  which  the  contractor  must  meet  for  compliance. 

C.  PROVISIONING  PROCESSING  PHASE 


The  provisioning  processing  phase  begins  when  the  PTD  is 
received  from  the  contractor.  Processing  in  this  phase  is 
generally  performed  on  a  package  basis. 

1.  Input  s .  The  primary  input  to  this  processing  phase  is 
the  PTD  prepared  by,  and  received  from,  the  end  item  contractor. 

2.  Fi les .  The  files  used  in  the  provisioning  process  vary 
from  Component  to  Component.  The  Army  has  established  permanent 
automated  files  dedicated  to  provisioning  actions,  as  has  the  Air 
Force  in  its  automated  provisioning  subsystem.  The  Navy  gener¬ 
ally  uses  temporary  storage  files  in  the  provisioning  process  with 
all  provisioning  data  being  transferred  to  permanent  operational 
files  prior  to  the  requirements  determination  process.  The  Marine 
Corps,  like  the  Navy,  tends  to  use  permanent  operational  files 

for  storage  of  provisioning  data.  In  each  case,  the  type  files 
used  and  the  file  structure  depend  on  the  ADP  technology  and 
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equipment  present  at  the  provisioning  activity.  Generally,  manual 
functional  provisioning  files  are  also  maintained  for  each  pro¬ 
visioning  pro j ec t / con t r a c t  . 

3 .  Processing 


The  provisioning  technical  documentation  must  be  reviewed 
and  accepted  prior  to  commencement  of  the  major  events  in  the 
provisioning  phase.  This  may  be  performed  by  a  single  individual 
or  by  a  group  of  individuals  as  a  joint  effort.  This  review  must 
be  performed  to  ensure  that  all  required  provisioning  data  is 
present  and  entered  correctly  in  the  PTD.  Provisioning  Data  not 
present  or  faulty  in  format  or  content  should  be  corrected  by 
the  contractor  prior  to  acceptance  of  the  PTD.  When  the  PTD  is 
accepted,  the  contractor  may  not  be  easily  persuaded  to  furnish 
omitted  data  or  correct  faulty  data.  In  at  least  one  Service 
this  review  process  is  partially  automated  in  the  form  of  a  vali¬ 
dation  routine  prior  to  establishing  items  on  provisioning  files. 
Although  the  study  team  received  reports  that  the  review  proce¬ 
dure  was  too  lengthy  and  expensive  for  the  value  gained,  it  must 
be  recognized  that  many  of  the  LISSR  rejects  originate  from  this 
PTD.  The  most  notable  of  these  rejects  are  invalid  FSCMs  and 
Part  Numbers.  The  time  taken  to  review  this  data  could  be  re¬ 
duced  by  using  mechanized  submittal  as  provided  by  MIL-STD-1552 
and  using  automated  validation  procedures  as  a  portion  of  the 
review  process. 

After  the  provisioning  documentation  has  been  reviewed 
and  accepted,  the  six  major  events  shown  in  the  conceptual  systems 
model  may  be  commenced.  The  major  events  include: 

*  Catalog  Data  Screening 

*  File  Establishment 

*  SM&  R  Coding 

*  IMC 

*  File  Maintenance 

*  Requirements  Determination 

a.  Catalog  Data  Screening.  Subsequent  to  acceptance  of 
the  PTD,  the  provisioning  activity  generally  performs  catalog 
data  screening.  Only  the  Army  currently  automatically  generates 
screening  transactions;  the  other  Services  all  initiate  screen¬ 
ing  actions  on  a  manual  basis.  If  contractor  screening  was  per¬ 
formed,  items  which  match  to  one  or  more  existing  NSNs  have  NSN 
inquiries  generated  instead  of  screening  actions.  These  inquiries 
return  Management  Data  needed  to  process  these  items.  The  screen¬ 
ing  and  inquiry  processing  performed  may  be  against  local  opera¬ 
tional  files,  DLSC  files  or  both.  As  mentioned  above,  only  the 
Army  directly  initiates  screening  and  inquiry  actions  on  a 
mechanized  basis;  however,  all  the  Services  generally  maintain 
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automated  suspense  files  of  screening/inquiry  transactions  gener¬ 
ated  and  awaiting  a  reply.  It  is  also  important  to  note  that  in 
this  processing  phase  only  the  Navy  performs  automated  decision 
making  using  screening  replies.  The  other  Services  all  process 
these  screening  replies  manually.  DLSC  screening  transactions 
generated  in  the  provisioning  processing  phase  generally  contain 
a  priority  of  '2'  or  '4,'  and  the  type  screening  performed  is 
generally  type  'S'  or  ' F '  except  in  the  Navy  where  type  'P' 
screening  is  normally  performed.  The  type  of  screening  performed 
has  a  direct  bearing  on  the  replies  received. 

b.  File  Establishment.  The  automated  files  established 
for  use  in  the  provisioning  processing  phase,  whether  permanent 
provisioning  type  files  like  the  Army  uses  or  temporary  storage 
files  like  the  Navy  uses,  store  provisioning  data  on  an  item 
basis;  program  or  provisioning  package  data  is  usually  maintained 
in  separate  automated  files.  Manual  files  are  distinctly  dif¬ 
ferent  in  that  o  single  file  generally  contains  an  entire  provi¬ 
sioning  project.  These  manual  files  lend  themselves  to  the  pack¬ 
age  processing  methodology  used  by  each  of  the  Services.  The 
provisioning  data  entering  automated  files  usually  is  subjected 
to  a  rigorous  validation  routine  which  must  be  passed  prior  to 
entrance  on  the  file.  Some  activities  also  send  technical  data 
received  to  the  activity  technical  repository  for  review  and 
duplication  as  part  of  File  Establishment. 

c.  SM&  R  Coding.  Source,  Maintenance,  and  Recoverability 
codes  are  generally  manually  assigned  by  a  provisioner  or  equip¬ 
ment  specialist.  At  this  time  other  maintenance  data  is  reviewed 
and  assigned. 

d.  I MC .  The  Item  Management  Code  is  also  usually  man¬ 
ually  assigned  for  new  items.  The  cataloging  data  is  also 
reviewed  and  assigned  at  this  point  in  processing.  This  cata¬ 
loging  data  includes  such  data  elements  as  FSC,  managing  activity 
and  Shelf  Life  Code.  For  new  items  entering  the  DoD  Supply 
System  the  data  elements  may  have  to  be  assigned  from  the  PTD, 
while  for  established  items  they  may  be  extracted  from  the 
results  of  catalog  data  screening. 

e.  File  Maintenance.  When  the  maintenance  and  catalog¬ 
ing  data  has  been  assigned  to  each  item  iri  the  provisioning  pro¬ 
ject,  this  data  is  generally  entered  on  EAM  cards  for  tile  posting. 
The  data  contained  on  the  EAM  cards  is  again  subjected  to  rigorous 
automated  validation  prior  to  being  entered  on  provisioning/ 
operational  files.  At  this  point  in  the  processing,  items  within 
the  provisioning  package  fall  into  four  categories. 
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'1)  Items  not  to  be  supported 


(2)  Items  retained  for  management  by  the  provi¬ 
sioning  activity* 

(3)  Consumable  items  managed  by  another  activity 
(SSR  candidates). 

(4)  Nonconsumable  items  managed  by  another  activity 
( NIMSR  candidates). 


f.  Requirements  Determination.  The  category  into  which 
each  item  falls  determines  whether  or  not  the  requirements  deter¬ 
mination  process  is  necessary,  and  if  necessary,  the  particular 
formulas  to  be  used  or  computations  to  be  performed.  In  the  Army 
and  Navy,  the  requirements  computation  is  usually  performed  on 
an  automated  basis  while  in  the  Air  Force  and  Marine  Corps,  it 


i 8  usually  a  manual  process. 


4.  Outputs .  Output  from  the  provisioning  processing  phase 
consists  of  the  four  categories  of  items  described  above.  No 
further  processing  is  performed  on  items  which  are  not  to  be 
supported.  Retained  items  are  usually  forwarded  to  item  mana¬ 
gers  within  the  provisioning  activity  for  further  processing. 
NIMSR  candidate  processing  is  discussed  in  Section  J.  below.  SSR 
candidates  are  passed  along  with  appropriate  technical  data  to 
the  SICC  SSR  Processing  Phase. 


5.  Controls .  The  major  controls  used  in  the  provisioning 
processing  phase  are  the  manual  provisioning  project  folders  and 
various  listings  produced  as  a  result  of  automated  processing. 
These  automated  listings  contain  transactions  in  error  and  those 
which  were  successfully  added  or  updated  in  the  provisioning 
files. 


D.  SICC  SSR  PROCESSING  PHASE 

SICC  SSR  processing  begins  after  SSR  candidates  have  been 
identified  and,  in  most  cases,  after  the  requirements  computation 
process  has  been  completed.  Processing  in  this  phase  may  be  on 
an  end  item  or  a  provisioning  package  basis  depending  on  the 
Component/Activity .  The  Components  have  generally  developed 
automated  processing  of  SSR  candidates  in  a  separate  systems 
design,  although  in  most  cases  this  processing  is  a  direct  follow 
on  from  provisioning  and/or  requirements  computation.  The  degree 
of  automation  also  varies  significantly  in  this  area,  both  from 
the  standpoint  of  types  of  SSR  transactions  mechanically  gener¬ 
ated,  and  mechanical  generation  of  changes  resulting  from  Design 
Change  Notices  (DCNs). 


87 


V* 


i 


1 .  Inputs 


There  are  basically  two  types  of  Inputs  to  the  SICC  SSR 
processing  phase.  The  first  type  Is  SSR  candidates  and  asso¬ 
ciated  technical  data.  The  second  type  is  inquiries  into  auto¬ 
mated  SSR  files.  All  inputs  are  assumed  to  be  in  random  sequence 
requiring  sorting  prior  to  processing. 

The  SSR  candidates  at  this  point  in  processing  may  be  in 
the  format  of  SSR  transactions  or  they  may  be  in  a  combined 
PDSSR/LISSR  transaction  format  or  they  may  be  in  the  format  of 
manual  provisioning  data.  The  candidates  may  be  passed  directly 
to  the  SICC  SSR  processing  phase  from  the  provisioning  processing 
phase  on  an  automated  basis,  or  the  action  may  be  manual.  The 
study  team  found  both  situations  partially  as  a  result  of  system 
design  and  partially  because  of  the  degree  of  automated  system 
implementation.  Technical  data  passed  from  the  provisioning  pro¬ 
cessing  phase  is  generally  hard  copy  drawings  or  aperture  cards. 

Inquiry  transactions  are  manually  generated  and  extract 
data  from  the  Component  SSR  Suspense  File  for  a  single  item  or 
all  items  within  a  PCC. 

2 .  Files 

At  most  Component  activities,  manual  files  are  maintained 
on  both  active  SSR  items  and  completed  SSR  items.  The  active 
files  are  usually  kept  and  maintained  by  the  individual  respon¬ 
sible  for  processing  the  item.  When  the  SSR  transactions  have 
been  submitted,  the  item  may  be  transferred  to  a  central  file 
containing  active  items.  Completed  items  are  generally  kept  in 
a  central  file.  The  contents  and  number  of  these  files  (both 
active  and  history)  vary  to  a  great  extent  from  Component  to 
Component  due  to  the  differing  systems  design  concepts  used. 

These  manual  files  are  generally  maintained  in  PCC,  ISN,  and  DOR 
sequence . 

All  Services  have  included  an  SSR  Suspense  File  as  part 
of  their  automated  systems  design.  These  automated  files  contain 
both  active  and  completed  items.  The  organizational  structure 
of  these  files  varies  from  Component  to  Component;  however,  it 
is  primarily  a  sequential  magnetic  tape  file  except  in  the  Army; 
where  a  complex  indexed-sequential,  variable  length  record,  disk 
file  is  used.  The  type  of  transactions  maintained  in  these  files 
also  varies  from  Service  to  Service.  For  example,  some  system 
designs  allow  only  valid  transactions  to  be  posted  to  this  file, 
while  others  allow  both  valid  and  invalid  transactions  to  be 
posted.  Also,  the  Navy  posts  file  maintenance  transactions  on 
this  file,  while  the  other  Services  generally  do  not.  The  type 
of  SSR  transactions  posted  also  varies;  for  example,  the  Air 
Force  does  not  post  followup  transactions  to  its  SSR  Suspense 
File. 
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The  retention  period  and  purge  criteria  of  both  manual 
and  automated  files  vary  from  Service  to  Service.  The  active 
manual  files  are  generally  purged  on  an  Item  basis  by  transferring 
the  item  to  a  manual  history  file  when  a  final  accept  or  final 
reject  advice  is  received  from  an  IMM.  These  manual  history 
files  are  maintained  for  a  period  of  two  years  after  the  PCC  has 
been  completed.  This  two-year  period  is  consistent  with  the  IMM 
Manual  requiring  SSR  change  transactions  to  be  submitted  for  two 
years  following  completion  of  the  PCC.  After  the  two-year  'period 
these  changes  are  to  be  submitted  as  initial  submittal  SSR  trans¬ 
actions.  Maintenance  of  a  history  file  for  two  years  provides  a 
record  of  SSR  data  required  for  these  change  transactions.  The 
automated  files  are  maintained  for  varying  lengths  of  time  (from 
120  days  to  one  year)  and  may  be  purged  on  a  PCC  or  item  basis. 
There  currently  is  no  specific  requirement  in  the  IMM  Manual  for 
maintenance  of  a  suspense  file  of  SSR  transactions/actions  by 
the  SICC. 


Generally,  each  Service  systems  design  allows  for  in¬ 
quiries  into  the  automated  SSR  Suspense  File.  These  inquiries 
are  input  and  processed  during  the  normal  processing  cycle  of 
the  Component  SSR  Application.  The  output  from  these  inquiries 
varies  from  Service  to  Service  depending  on  the  requests  and 
transactions  resident  on  the  SSR  Suspense  File. 

3 .  Processing 

Manual  processing  in  this  processing  phase  is  generally 
on  a  package  basis,  while  automated  processing  is  usually  accom¬ 
plished  item  by  item.  Only  the  Marine  Corps  has  an  established 
priority  for  processing  SSR  candidates.  This  prioritisation  is 
on  a  manual  basis  and  results  in  retained  items  being  processed 
first  followed  by  part  number  SSR  transactions  being  generated 
and  submitted  with  NSN  SSR  transactions  being  generated  and  sub¬ 
mitted  last.  Each  Component  has  established  SSR  generation  cri¬ 
teria  which  each  SSR  candidate  must  meet  prior  to  SSR  transaction 
generation  and  submittal.  This  criteria  varies  widely  from 
Service  to  Service  and  even  by  activity  within  Service.  For 
example,  if  the  requirements  computation  process  results  in  zero 
quantities  the  Marine  Corps  will  not  generate  an  SSR  for  these 
items.  The  Navy  uses  MOE  Rule  data  for  NSN  items  as  a  portion 
of  its  SSR  generation  criteria,  while  the  Air  Force  uses  dollar 
value  as  part  of  its  criteria.  This  variance  in  criteria  illus¬ 
trates  the  confusion  over  the  intent  and  purpose  of  SSR  transac¬ 
tions  . 

SICC  SSR  processing  consists  of  four  major  events  as 
shown  in  the  Conceptual  Systems  Model  (Figure  V-l).  These  major 
events  include: 

*  Catalog  Data  Screening 

*  Edit  Validation 

*  Requirements  Determination 

*  File  Maintenance 
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These  major  events  are  performed  as  a  combination  of  manual  and 
automated  processes.  Manual  processing  (and  generally  scheduling 
automated  processing)  falls  under  a  single  functional  element  at 
each  SICC  activity,  such  as  the  Data  Management  Branch  in  the 
Army  at  TSARCOM.  This  single  functional  element  has  the  respon¬ 
sibility  of  matching  up  technical  data  with  SSR  transactions, 
preparing  transmittal  letters,  mailing  SSRs  to  the  proper  IMMs 
and  maintaining  manual  files.  This  functional  element  usually 
establishes  a  manual  file  for  each  PCC  package  when  it  reaches 
this  processing  phase.  This  file  establishment  is  discussed  as 
a  separate  major  event  below.  Figure  V-2  shows  the  sequence  of 
major  events  performed  by  each  of  the  SICC  Services.  This  figure 
illustrates  the  variance  in  the  number  of  major  events  performed 
from  Service  to  Service,  but  notice  the  similarity  in  the  sequence 
of  performance  among  the  Services.  The  major  events  within  this 
processing  phase  are  discussed  below  in  the  sequence  shown  for 
the  Air  Force,  since  this  Service  performs  the  majority  of  the 
events . 

SICC  SSR  PROCESSING  PHASE 
SEQUENCE  OF  MAJOR  EVENTS  BY  SICC  SERVICE 


Army 

Navy 

Air  Force 

Marine  Corps 

-  Validation 

-  File 

Maintenance 

-  Technical  Data 

Tracking 

— - 

-  Validation 

-  File 

Maintenance 

-  File 

Establishment 

-  Validation 

-  DLSC  Screen 

-  Requirements 

Computation 

-  File 

Maintenance 

-  File 

Maintenance 

Source:  Field  Research 


Figure  V-2 

a .  File  Establishment 

Manual  files  are  established  by  each  SICC  when  tech¬ 
nical  data  from  the  provisioning  processing  phase  is  passed  to 
the  functional  element  responsible  for  sending  SSR  transactions 
to  IMMs.  This  technical  data  may  or  may  not  be  accompanied  by 
SSR  data  or  SSR  transactions.  The  activities  operating  under  an 
automated  SSR  system  which  receives  SSR  candidates  directly  from 
an  automated  provisioning  or  requirements  computation  process, 
manually  pass  technical  data  only.  A  manual  file  is  established 
usually  based  on  PCC  to  hold  this  technical  data  until  the  SSR 
transactions  for  that  PCC  are  generated  for  submittal  to  IMMs. 
The  technical  data  stored  In  these  files  may  or  may  not  have 
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required  control  data  elements  annotated  (PCC,  ISN,  ACT,  ACP, 

DOR) .  The  PCC,  ISN,  ACT,  ACF  of  each  of  these  items  have  been 
determined  during  the  Provisioning  Processing  Phase  by  provi¬ 
sioning  and  cataloging  personnel.  This  technical  data  is  used 
to  determine  the  technical  and  cataloging  data  required  in  Part 
Number  SSR  transactions.  When  this  control  data  has  not  been 
annotated  on  the  technical  data,  it  must  wait  for  the  SSR  trans¬ 
actions  to  be  generated  by  the  automated  process  before  it  may 
be  annotated  with  control  data.  Under  the  current  mode  of  pro¬ 
cessing  with  both  SSR  transactions  and  technical  data  being 
mailed  together  this  is  not  a  problem;  however,  under  the  AUTODIN 
submittal  concept  presented  in  Volume  III,  this  control  data 
should  be  annotated  during  the  provisioning  process  so  the  tech¬ 
nical  data  may  be  prepared  for  mailing  immediately  rather  than 
sitting  in  a  manual  file  awaiting  SSR  transaction  listings  from 
which  the  needed  control  data  may  be  obtained. 


The  Navy  may  establish  program  data  on  its  Program 
Data  Record  (PDR)  at  this  point  in  processing.  This  file  may 
then  be  used  to  extract  data  to  build  PDSSR  transactions  to 
accompany  USSR  transactions  from  the  provisioning  subsystems  or 
LISSR  transactions  that  are  manually  generated  and  input  to  the 
SSR  Application.  The  Army  and  Air  Force  have  also  adopted  this 
concept  of  drawing  PDSSR  transaction  data  from  current  files; 
however,  their  particular  method  is  slightly  different.  Once  a 
PDSSR  transaction  is  posted  to  the  SSR  Suspense  Files  of  these 
Services,  LISSR  transactions  input  without  a  PDSSR  transaction 
will  extract  PDSSR  transaction  data  from  the  SSR  Suspense  File. 
When  a  PDSSR  transaction  with  identical  control  data  elements  to 
one  already  on  the  file  is  input,  it  serves  to  update  the  SSR 
Suspense  File  only;  the  second  PDSSR  transaction  is  not  added  to 
the  file.  Although  it  appears  that  PDSSR  transaction  data  is 
established  in  automated  files  primarily  to  meet  the  SSR  package 
requirements,  it  must  be  noted  that  the  Navy  and  Air  Force  as 
SICCs  allow  additional  program  data  outside  of  that  required  in 
PDSSR  transactions  to  be  stored  in  these  automated  files. 


b.  Validation/ Editing 


This  is  the  first  major  event  within  this  processing 
phase  performed  on  an  automated  basis.  The  Army,  Navy  and  Air 
Force  all  have  automated  validation  of  SSR  transactions  designed 
into  their  automated  SSR  Applications.  The  validation  performed 
by  the  Marine  Corps  is  on  a  manual  basis.  SSR  transactions  are 
sorted  prior  to  being  validated  in  the  automated  systems.  In 
the  Air  Force  a  sort  key  is  appended  to  each  transaction  prior 
to  the  mechanized  sort.  The  data  elements  used  in  this  sorting 
process  is  shown  in  Figure  V-3.  In  each  case  the  data  elements 
are  listed  in  the  sort  sequence  sorted  with  the  major  sort  con¬ 
trol  at  the  top  of  each  list. 
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SORT  SEQPENCE  BY  SERVICE 


Army 

Navy 

Air  Force 

PCC 

PCC 

PCC 

ACT 

ACT 

ISN 

ACF 

ISN 

DOR/Document  No. 

DOR 

DOR 

Transaction  Date  1/ 

1SN 

DIC 

DIC 

DIC 

TCC 

Card  No. 

Card  No. 

Card  No. 

Source:  Systems  Design  Documentation. 


1 /  The  Transaction  Date  is  a  computer  assigned  date 

Indicating  the  date  the  transaction  is  processed  by  the 
computer . 


Figure  V-3 

This  figure  shows  that  although  many  of  the  same 
data  elements  are  used  to  control  the  sequence  of  processing  SSR 
transactions,  the  SSR  transactions  are  processed  in  different 
sequences  in  each  system  due  to  the  different  data  elements  used 
by  each  Service  and  the  order  in  which  the  data  elements  occur 
in  the  sort  sequence.  In  each  of  the  automated  systems,  trans¬ 
actions  may  be  sorted  more  than  once;  however,  the  sort  sequence 
is  generally  the  same  and  this  same  sequence  is  generally  used 
for  posting  transactions  to  Service  SSR  Suspense  Files. 

The  validation  conventions  and  criteria  used  by  each 
of  the  Services  are  discussed  in  Volume  111.  Generally,  the  con¬ 
ventions  are  centered  around  a  stand-alone  validation  program 
for  data  element  level  validation  with  other  levels  of  valida¬ 
tion  (package,  duplicate,  etc.)  performed  as  part  of  file  main¬ 
tenance  actions.  The  criteria  used  by  each  of  the  Services 
generally  Includes  strict  validation  of  the  data  elements  used 
for  sequencing,  control  and  quantitative  data  with  other  data 
elements  being  bypassed,  or  edited  to  a  nonerror  condition. 

c.  Catalog  Data  Screening.  The  Air  Force  is  the  only 
Service  to  have  designed  a  screening  process  into  the  SSR  Appli¬ 
cation.  This  is  an  automated  process  both  from  the  standpoint 
of  screening  transaction  generation  and  screening  result  inter¬ 
pretation  and  processing.  The  screening  performed  is  against 
DLSC  files  only  and  is  done  for  NSN,  PSCN,  and  Fart  Number  SSR 
transactions.  The  screening  replies  are  matched  to  the  correspond 
ing  SSR  transaction  and  certain  data  elements  are  checked  for  com¬ 
patibility  (AAC,  U/I,  etc).  When  a  Part  Number  matches  to  an  NSN, 
or  multiple  NSNs ,  or  incompatibilities  requiring  manual  action 


exist,  the  SSR  transaction  and  DLSC  screening  replies  are  output 
on  functional  listings  for  manual  review.  Some  data  on  the  SSR 
transaction  may  be  automatically  changed  to  be  made  compatible 
with  DLSC  file  data. 

d.  Requirements  Computation.  This  major  event  la  gener¬ 
ally  performed  only  by  the  Air  Force  during  this  processing  phase. 
Currently,  the  Air  Force  has  no  separate  automated  requirements 
computation  application.  Therefore,  SSR  quantities  must  be  man¬ 
ually  computed  or  certain  computation  factors  must  be  placed  in 
SSR  quantity  fields  to  enable  the  automated  SSR  Application  to 
compute  these  quantities.  Since  dollar  value  is  part  of  the  Air 
Force  SSR  generation  criteria,  the  SSR  transactions  remain  in 

the  SSR  candidate  status  until  after  this  major  event  has  been 
completed . 

e .  File  Maintenance 

This  major  event  is  performed  on  a  manual  and  auto¬ 
mated  basis  by  the  Army,  Navy  and  Air  Force.  It  is  performed  on 
a  manual  basis  by  the  Narine  Corps.  The  posting  of  SSR  transac¬ 
tions  to  the  automated  SSR  Suspense  File  is  generally  the  final 
automated  action  taken  prior  to  producing  EAM  card  SSR  transac¬ 
tions.  The  actual  transactions  posted  are  discussed  in  conjunc¬ 
tion  with  the  validation  conventions  in  Volume  III  and  vary  from 
Service  to  Service.  As  mentioned  earlier  in  this  subsection, 

SSR  transactions  are  generally  posted  to  this  file  in  the  sequence 
dictated  by  sort  sequences  shown  in  Figure  V-3. 

Manual  file  maintenance  Includes  matching  technical 
data  to  Part  Number  SSR  transactions  in  preparation  for  mailing. 
The  Army,  Navy,  and  Air  Force  have  all  Included  automatic 
generation  of  Item  Name  Transactions  for  each  Part  Number  SSR 
generated.  These  item  name  transactions  are  manually  separated 
from  the  Part  Number  SSR  transactions  for  which  technical  data 
is  present  during  this  major  event.  A  manual  suspense  file  of 
SSR  transactions  mailed  is  also  maintained  for  followup  purposes. 

The  study  team  found  that  automatic  generation  of 
followup  transactions  specified  by  the  IMM  Manual  are  included 
in  the  automated  systems  design  of  each  Service.  However,  during 
the  operational  Implementation  review  only  the  Air  Force  system 
had  been  fully  implemented  and  the  other  Services  were  either 
not  following  up  on  overdue  SSR  transactions,  or  were  using  cor¬ 
respondence  or  telephone  calls  as  a  followup  procedure.  This  was 
also  illustrated  in  the  data  collection.  The  data  collection  and 
system  design  review  Indicated  that  the  Services  were  following 
up  30-40  days  from  the  DOR.  The  assignment  of  this  DOR  has  been 
discussed  in  Volumes  II  and  III  and  was  found  to  be  assigned  dif¬ 
ferently  by  each  Service  and  did  not  necessarily  reflect  the  date 
the  SSR  transaction  was  actually  submitted  to  an  IMM.  In  fact, 
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the  SSR  transactions  may  have  been  submitted  10  days  to  two  weeks 
after  the  DOR.  This  does  not  allow  the  IMM  adequate  processing 
time  and  Is  partly  responsible  for  the  high  number  of  'No  Record' 
followup  responses  received  by  the  Air  Force.  This  situation  of 
generating  followups  too  early  can  be  solved  by  basing  genera¬ 
tion  of  followup  transactions  on  the  data  the  SSR  is  submltted- 
not  on  the  DOR. 

f.  Technical  Data  Tracking.  A  procedure  was  found  at 
one  activity  for  submission  of  technical  data  subsequent  to  SSR 
submission.  When  technical  data  was  expected  to  be  received 
from  the  contractor,  but  had  not  been  received  by  the  time  the 
SSR  transaction  for  the  item  was  ready  for  submission,  this 
activity  would  place  a  Date  Technical  Data  to  be  Supplied  in 
the  SSR  transaction  and  submit  it  to  the  appropriate  IMM.  The 
automated  system  would  periodically  generate  a  notification  to 
the  technical  data  repository  that  technical  data  was  to  be  sub¬ 
mitted  to  the  IMM  when  received.  Periodic  followups  are  auto¬ 
matically  generated  to  the  technical  data  repository  until  cleared 
from  the  automated  suspense  file.  This  type  of  system  or  proce¬ 
dure  appears  to  be  valuable  not  only  from  the  standpoint  of  sub¬ 
mission  of  technical  data  promised  to  IMMs  but  also  from  the 
standpoint  of  following  up  to  the  contractor  for  outstanding 
technical  data  required  by  the  contract. 

A .  Outputs 

The  SICC  SSR  Processing  Phase  produces  several  outputs 
including  outgoing  SSR  transactions,  followup  transactions,  and 
various  functional  outputs  as  hard  copy  listings,  microfiche 
listings,  correspondence  and  EAM  cards.  Outgoing  SSR  transac¬ 
tions  are  combined  with  applicable  technical  data  and  mailed  to 
IMMs.  Followup  transactions  are  generally  designed  to  be  placed 
on  intermediate  storage  (disk  or  magnetic  tape)  for  subsequent 
transmittal  to  IMMs  via  AUTODIN. 

Each  of  the  automated  systems  are  designed  to  produce 
various  listings  for  functional  use.  These  listings  generally 
provide  to  functional  users  the  automated  processing  actions 
taken;  e.g.,  SSR  transactions  rejected  for  invalid  data,  or 
valid  SSR  transaction  generated  for  submittal.  The  Air  Force 
produces  certain  listings  on  microfiche  rather  than  hard  copy. 

The  Navy  system  is  designed  to  generate  form  letters  to  contrac¬ 
tors  requesting  technical  data  be  sent  directly  to  IMMs  when  a 
Date  Technical  Data  to  be  Provided  is  included  in  the  SSR  trans¬ 
action.  The  Army  and  Navy  systems  provide  EAM  cards  to  serve 
as  correction  cards  for  SSR  transactions  rejected  due  to  entry 
of  invalid  data;  the  Navy  blanks  out  the  erroneous  data  in  these 
transactions.  The  only  statistical  reports  produced  for  this 
processing  phase  are  counts  of  SSR  transactions  generated.  These 
counts  reflect  current  processing  cycle  data  only,  no  accumula¬ 
tion  is  done  either  on  a  manual  or  an  automated  basis. 
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Manual  outputs  from  this  processing  phase  Include  cor¬ 
respondence  In  the  form  of  cover  letters  forwarding  SSR  trans¬ 
action  packages  and  the  correspondence  followup  mentioned  above* 
Some  SSR  transactions  may  be  manually  generated  and  processed 
outside  the  automated  systems  design,  particularly  in  the  Marine 
Corps  . 

5*  Controls .  Manual  processing  for  the  most  part  appeared 
to  be  loose  and  disjointed  with  little  or  no  control  over  item 
processing.  Some  of  the  automated  listings  were  used  to  control 
manual  followup  actions.  Automated  control  is  based  primarily 
on  the  data  elements  used  to  sort  transactions  prior  to  and 
during  processing  in  the  automated  system.  Followup  actions  are 
included  in  each  automated  system  and  are  controlled  by  the  DOR 
of  each  SSR  transaction  and  the  time  standard  set  by  the  IMM 
Manua 1 . 

E .  IMM  SSR  PROCESSING  PHASE 

The  discussion  of  this  processing  phase  is  divided  into  two 
sections.  The  first  section  discusses  WIMM  SSR  processing;  the 
second  section  discusses  CIMM  SSR  processing.  This  separation 
is  necesary  because  of  the  varying  formats,  transactions  and 
processing  actions  performed  by  WIMM  activities  as  compared  to 
those  performed  by  CIMM  activities.  SSR  resubmissions  are  pro¬ 
cessed  the  same  as  original  submissions  by  both  CIMMs  and  WIMMs 
with  no  reference  or  processing  relationship  to  previous  submit¬ 
tals. 


1.  WIMM  SSR  Processing 


The  receipt  of  SSR  transactions  from  SICCs  begins  this 
processing  phase.  SSR  transactions  received  by  WIMMs  consist 
primarily  of  items  already  assigned  NSNs  .  The  IMM  Manual  pro¬ 
vides  for  submission  of  PSCN  and  Part  Number  SSR  transactions  to 
W IMM 8  for  joint  provisioning  actions  only.  These  joint  provi¬ 
sioning  generated  SSRs  are  discussed  in  Section  I.  below.  It  is 
significant  to  note  that  the  automated  systems  designs  of  the 
Services  acting  as  WIMMs  provide  for  processing  all  types  of  SSR 
transactions;  while  on  a  manual  basis  the  operational  review 
indicates  first  that  few  PSCN  or  Part  Number  SSR  transactions 
are  received  and  second  when  they  are  received,  they  are  rou¬ 
tinely  rejected  for  support. 


The  functional  elements  responsible  for  packaging  and 
mailing  outgoing  SSR  transactions  as  a  SICC  are  generally  those 
elements  where  incoming  SSR  transactions  are  received  and  ini¬ 
tially  processed.  The  Army  and  Air  Force  automated  system  design 
provides  for  processing  outgoing  and  Incoming  SSR  transactions 
in  the  same  program  modules  and  using  the  same  SSR  Suspense  File. 
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The  Navy  automated  systems  design  provides  for  separate  program 
modules  and  a  separate  SSR  Suspense  File  for  processing  incoming 
and  outgoing  SSR  transactions*  The  planned  Marine  Corps  auto¬ 
mated  systems  design  does  not  provide  for  mechanized  processing 
of  Incoming  SSR  transactions.  The  data  collection  results 
discussed  in  Volume  III  show  the  relatively  small  volume  of  WIMM 
transactions  as  compared  to  CIMM  transactions.  This  small  volume 
indicates  that  development  of  separate  program  modules  and  files 
for  processing  incoming  SSR  transactions  does  not  appear  to  be 
justified  and  the  automated  processing  of  incoming  SSR  transac¬ 
tions  should  be  combined  with  outgoing  SSR  transaction  processing. 

a.  Inputs .  Inputs  to  this  processing  phase  generally 
consist  of  NSN  SSR  transactions  and  followup  transactions. 

Because  almost  all  SSR  transactions  received  contain  NSNs , 
offers  of  alternate  or  substitute  items  are  seldom  made;  as  a 
result  offer  reply  transactions  are  seldom  received  for  pro¬ 
cessing. 


b .  Files 


WIMM  activities  generally  maintain  both  automated 
and  manual  files.  Each  Component  activity  maintains  an  automated 
SSR  Suspense  File  and  is  the  same  file  that  contains  outgoing 
SSR  transactions  except  in  the  Navy.  The  WIMM  SSR  Suspense  File 
in  the  Navy  has  the  same  structure  and  is  maintained  in  the  same 
sequence  as  the  SICC  SSR  Suspense  File. 

The  manual  files  maintained  are  generally  historical 
type  files.  These  historical  files  contain  the  original  SSR 
transactions  submitted  and  the  advice  provided  for  each  item. 

These  files  may  be  maintained  on  an  item  basis,  as  in  the  Navy, 
or  on  a  PCC  basis,  as  in  the  Air  Force.  These  manual  files  are 
generally  maintained  for  180  days  after  advice  is  provided  the 
SICC.  This  timeframe  meets  the  IMM  Manual  criteria  that  IMMs 
must  maintain  a  record  of  advice  provided  for  120  days;  however, 
this  timeframe  makes  automated  matchup  of  change  transactions 
which  may  be  submitted  up  to  two  years  after  the  DOR  of  the  ini¬ 
tial  submission  virtually  impossible  after  the  120  days  have 
elapsed  and  the  file  is  purged.  This  same  matchup  problem  also 
exists  in  the  automated  SSR  Suspense  Files  where  items  are  auto¬ 
matically  purged  120  days  to  one  year  after  advice  is  furnished. 

Each  WIMM  activity  maintains  local  cataloging  files 
containing  the  same  Information  as  the  DLSC  TIR  file.  These 
local  TIR  files  play  an  important  role  in  incoming  SSR  processing. 
This  role  becomes  clear  in  the  discussion  of  major  event  pro¬ 
cessing  below. 

c.  Processing .  Incoming  SSR  transactions  are  processed 
on  an  item  basis  in  the  automated  systems  of  each  of  the  Services. 
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Manual  processing  actions  are  accomplished  on  a  PCC  package  basis 
In  the  Array  and  Navy,  and  on  an  item  basis  in  the  Air  Force  and 
Marine  Corps*  The  major  events  performed  manually  and  those 
performed  mechanically  vary  from  Service  to  Service.  This  will 
be  made  clear  in  the  discussion  of  each  major  event.  The  se¬ 
quence  of  major  events  performed  in  this  processing  phase  is 
shown  by  Service  in  Figure  V-4. 

WIMM  S SR  PROCESSING  PHASE 
SEQUENCE  OF  MAJOR  EVENTS  BY  WIMM  SERVICE 


_ Army _ _ Navy _ Air  Force _ Marine  Corps 

-Validation/Edit  -Validation/Edit  -Validation/Edit  -Catalog  Data 
-Catalog  Data  -Advice  Decision  -File  Maintenance  Screening 
Screening  -File  Maintenance  -Advice  Decision  -Advice 

-Advice  Decision  -Catalog  Data  -File  Maintenance  Decision 

-File  Mainte-  Screening  -Method/Level  of  -File  Mainte¬ 
nance  -Advice  Decision  Support  nance 

-Catalog  Actions  -File  Maintenance  -Requirements  '-Catalog  Data 
-Requirements  -Catalog  Actions  Determination  Screening 

Determination  -Requirements  -Advice  Decision  j -Catalog 

-Advice  Decision^  Determination  -File  Maintenance!  Actions 

- Va 1 ida t ion /Ed i t  -Requirements 
-File  Maintenance  Determina- 
.  -Catalog  Actions  tion 

-File  Maintenance  -Advice 
|  Decision 

|  -File  Mainte- 

_ _ _ _ I _ nance _ 

Source:  Field  Research 

Figure  V-4 

This  figure  illustrates  that  while  major  events  are  generally 
performed  in  a  similar  sequence  across  the  Services,  the  number 
of  times  certain  major  events  are  repeated  (although  they  do 
indicate  separate  actions)  extend  the  chain  of  major  events 
especially  in  the  Air  Force.  The  major  events  as  contained  in 
the  Conceptual  Systems  Model  (Figure  V-l)  are. 

*  Edit/Validation 

*  Catalog  Data  Screening 

*  Method/Level  of  Support 

*  Requirements  Determination 

*  File  Maintenance 

*  Advice  Decision 

*  Catalog  Actions 
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The  major  events  as  listed  in  Figure  V-4  indicate  the  sequence 
performed  as  experienced  during  the  operational  review.  Since 
only  the  Air  Force  had  implemented  automated  data  processing 
application  for  incoming  SSR  transactions  during  this  review, 
the  automated  actions  designed  in  the  Army  and  Navy  automated 
systems  are  not  apparent.  Due  to  the  repetitive  nature  of  some 
automated  and  manual  actions,  all  actions  performed  for  each 
major  event  are  combined  into  a  single  subsection  below.  The 
major  events  are  discussed  in  the  sequence  listed  on  the  Concep¬ 
tual  Systems  Model. 

(1)  Edit/Valldatlon.  This  major  event  is  generally 
performed  first,  both  on  a  manual  and  an  automated  basis.  The 
specific  automated  validation  conventions  and  criteria  are  dis¬ 
cussed  in  Volume  III.  There  is  a  significant  difference  in  the 
actions  taken  as  a  result  of  manual  validation  errors  encoun¬ 
tered  versus  automated  validation  errors  encountered.  When 
invalid  data  is  found  during  manual  validation,  the  data  element 
is  generally  corrected  and  the  SSR  transaction  continues  pro¬ 
cessing.  However,  in  the  automated  systems,  a  reject  advice 
transaction  is  generated  for  transmittal  to  the  SICC. 

( 2 )  Catalog  Data  Screening 

Catalog  Data  Screening  is  performed  by  all  Ser¬ 
vices  during  this  processing  phase.  Screening  on  an  automated 
basis  is  limited  to  local  cataloging  files  or  local  TIR  files 
and  in  the  Air  Force  this  is  the  only  screening  performed  on 
incoming  SSR  transactions.  Items  not  found  on  local  files  are 
screened  against  DLSC  files  by  the  Army,  Navy,  and  Marine  Corps. 
DLSC  screening  is  manually  initiated  and  screening  replies  are 
manually  processed  when  received. 

The  local  screening  performed  on  an  automated 
basis  in  the  Army  and  Navy  is  a  direct  file,  screen;  i.e.,  the 
screening  is  performed  in  the  SSR  Application  within  the  valida¬ 
tion  or  file  maintenance  program  modules.  In  the  Air  Force, 
local  file  screening  transactions  are  generated  and  output  to  a 
separate  application  which  then  performs  the  screening  action 
and  returns  the  results  to  the  SSR  Application  for  further  pro¬ 
cessing.  In  the  Army  and  Navy  items  not  matched  in  local  files 
are  file  maintained  and  output  for  manual  DLSC  screening;  matched 
items  continue  automated  processing.  All  items  whether  matched 
or  not  are  output  for  manual  action  in  the  Air  Force'  after  being 
file  maintained.  In  the  Army,  Navy,  and  Marine  Jorps  the  results 
of  screening  actions  bear  directly  on  the  advice  decision  while 
in  the  Air  Force  further  actions  are  performed  before  the  advice 
decision  is  made. 

(3)  Method/Level  of  Support  .  Although  only  Air 
Force  procedures  specify  this  event  to  be  performed  by  an  item 
manager,  field  research  indicated  it  was  either  not  performed  at 
all  or  did  not  alter  the  current  method  or  level  of  support  pro¬ 
vided  for  an  item. 
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(4)  Requirements  Determination.  The  actions  taken 
In  the  requirements  determination  area  vary  from  Service  to 
Service.  The  SSR  data  elements  frequently  used  in  the  require¬ 
ments  determination  process  are  the  retail  quantity,  replenish¬ 
ment  quantity  and  Unit  of  Issue.  None  of  the  Services  reserve 
assets  to  meet  SSR  requirements.  Some  WIMMs  under  certain  con¬ 
ditions  will  initiate  procurement  actions  as  a  result  of  SSR 
processing.  The  Army  automated  SSR  application  performs  an  asset 
availability  check  and  when  sufficient  assets  are  available  for 

an  item,  an  accept  advice  ATC  'YE'  (unconditional  support  accepted) 
will  automatically  be  generated  for  submittal  to  the  SICC.  The 
Navy  automatically  generates  planned  requirements  transactions 
to  be  lodged  in  requirements  files  to  be  used  in  the  requirements 
determination  process  for  SSR  items  accepted  for  support.  The 
Marine  Corps  places  a  hold  on  assets  which  would  normally  be 
declared  excess  in  response  to  SSR  requirements.  The  Air  Force 
does  not  generally  establish  requirements  on  the  basis  of  an  SSR. 

( 5 )  File  Maintenance 


File  maintenance  actions  applied  to  manual  files 
differ  from  those  applied  to  mechanized  files  both  in  content 
and  technique  on  an  intra  and  interservice  basis.  Generally  the 
SSR  data  elements  used  for  sequencing  and  control  of  these  files 
include  : 


*  Document  Identifier  Code 

*  Activity  Code  To 

*  Type  Change  Code 

*  Item  Serial  Number 

*  Date  of  Request 

*  Provisioning  Control  Code 

*  Activity  Code  From 

These  data  elements  are  not  used  consistently  by  all  the  Services 
for  all  files  or  even  for  all  files  within  a  single  Service/ 
Activity;  however,  these  are  the  data  elements  generally  described 
as  controls  by  the  Services.  The  sequence  in  which  these  data 
elements  are  used  also  differs  among  the  Services /Ac t 1 vi t i es . 

Both  active  and  completed  items  generally  reside 
in  the  same  file  at  WIMM  activities  regardless  of  whether  that 
file  is  manual  or  automated.  Manual  files  may  be  considered  to 
be  more  complete  than  their  respective  automated  counterpart 
because  these  manual  files  are  updated  with  each  incoming  LISSR 
transaction  prior  to  automated  processing.  When  an  invalid  data 
condition  is  encountered  in  automated  validation  a  reject  advice 
is  automatically  generated  for  the  item.  In  some  automated 
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systems  these  invalid  transactions  are  not  posted  to  the  SSR 
Suspense  File  as  discussed  in  Volume  III.  However,  these  trans¬ 
actions  do  reside  in  the  manual  file  and  the  reject  advice  is 
placed  with  the  item  as  a  history  record  of  the  action  taken. 

Manual  files  are  generally  maintained  at  two 
processing  points.  First,  when  SSR  transactions  are  initially 
received  they  are  posted  to  this  file.  The  second  file  main¬ 
tenance  action  is  posting  advice  to  each  item.  This  is  accomp¬ 
lished  by  annotating  the  advice  beside  each  item  when  the  file 
is  a  hard  copy  list ing/ ledger /et c .  A  duplicate  advice  transac¬ 
tion  is  generally  placed  with  the  original  SSR  transaction  when 
EAM  card  files  are  maintained. 

There  are  two  processing  points  where  automated 
files  are  maintained  also.  After  SSR  transactions  are  input  to 
automated  systems  they  undergo  several  processing  actions  before 
reaching  the  file  maintenance  action.  These  actions  may  Include 
validation  and  catalog  data  screening  among  others.  File  mainte¬ 
nance  at  this  point  varies  from  Service  to  Service.  Some  auto¬ 
mated  systems  post  all  valid  and  invalid,  LISSR  and  Advice  trans¬ 
actions  to  the  SSR  Suspense  File;  other  automated  systems  are 
designed  to  post  only  valid  transactions  to  the  SSR  Suspense 
File.  Generally,  only  Invalid  data  reject  advice  transactions 
are  present  at  this  processing  point;  however,  some  accept  advice 
transactions  may  be  present  in  the  Army  and  Navy  automated  sys¬ 
tems.  These  advice  transactions  are  output  for  transmittal  to 
the  SICC.  Items  requiring  an  advice  decision  are  output  gener¬ 
ally  as  a  listing  for  manual  review.  The  Navy  system  outputs  a 
skeleton  file  maintenance  card  for  each  item  requiring  a  manual 
advice  decision.  When  the  advice  is  determined,  it  may  be 
entered  in  the  file  maintenance  card  and  input  to  the  automated 
system.  This  card  then  updates  the  SSR  Suspense  File  and  gener¬ 
ates  an  advice  transaction  for  transmittal  to  the  SICC.  The 
other  Services  manually  code  and  keypunch  advice  transactions 
which  must  then  be  input  to  the  automated  systemd  for  validation 
and  file  maintenance.  These  automated  systems  also  generate  new 
advice  transactions  (identical  to  those  input,  when  valid)  for 
transmittal  to  the  SICC. 

Inquiries  to  the  automated  SSR  Suspense  File 
are  also  processed  as  file  maintenance  actions.  The  type  of 
inquiries  allowed  in  the  Army  and  Air  Force  systems  for  incoming 
SSR  transactions  are  identical  to  those  for  outgoing  SSR  trans¬ 
actions  discussed  under  SICC  SSR  Processing  Phase  above.  In  the 
Navy,  the  automated  systems  design  provides  for  a  separate  SSR 
Suspense  File  for  incoming  SSR  transactions.  The  Navy  automated 
systems  design  does  not  provide  for  inquiry  capability  to  this 


incoming  SSR  Suspense  File;  however,  it  does  provide  for  the 
entire  file  to  be  listed  as  hard  copy  as  the  final  processing 
step  in  every  processing  cycle. 

Processing  of  incoming  followup  transactions 
fall  under  file  maintenance  processing.  During  the  operational 
review,  the  Army  and  Navy  which  had  not  implemented  their  auto¬ 
mated  systems  were  performing  a  manual  check  of  the  incoming 
manual  SSR  History  File  to  determine  the  response  to  be  provided 
the  SICC.  The  Marine  Corps  follows  this  procedure  also.  Under 
the  Army  and  Navy  automated  systems  design,  followup  transactions 
will  be  processed  mechanically.  The  Air  Force  was  processing 
followup  transactions  mechanically  at  the  time  of  the  operational 
review.  The  automated  processing  of  followup  transactions  is 
generally  the  same  in  all  automated  systems.  Each  followup 
transaction  is  matched  to  the  SSR  Suspense  File  with  a  followup 
response  transaction  being  generated  automatically  based  on  the 
results  of  the  file  match  and  the  file  contents.  When  the  file 
contains  advice  information,  the  same  advice  is  forwarded  to  the 
SICC  in  a  followup  response  transaction.  When  a  matching  LISSR 
transaction  is  found,  but  no  advice  is  present  on  the  file;  the 
Army  and  Navy  output  the  followup  transaction  and  the  original 
SSR  data  as  a  functional  notification  that  advice  is  overdue. 

In  the  Air  Force,  a  followup  response  transaction  containing  ATC 
*67'  (advice  pending)  is  automatically  generated  for  transmittal 
to  the  SICC  -  no  functional  notification  is  produced.  When  the 
followup  transaction  cannot  be  matched  to  a  LISSR  transaction  on 
the  SSR  Suspense  File  the  Navy  and  Air  Force  automatically  gener¬ 
ate  a  response  using  ATC  '66'  (no  record)  for  transmittal  to  the 
SICC.  In  the  Army,  this  no  match  condition  creates  an  invalid 
transaction  situation  which  is  output  on  a  functional  notifica¬ 
tion  for  manual  review  and  action. 

( 6 )  Advice  Decision 

The  advice  decision  may  be  reached  on  an  auto¬ 
mated  or  manual  basis  and  varies  by  Service.  In  the  Marine  Corps 
where  no  automated  system  exists,  all  advices  are  reached  manually 
and  are  based  on  the  results  of  catalog  data  screening.  In  the 
other  Services  automated  advice  decisions  are  reached  as  a  result 
of  validation.  Invalid  data  reject  transactions  are  automati¬ 
cally  generated  and  output.  In  the  Air  Force,  all  other  advice 
decisions  are  made  manually.  In  the  Army  and  Navy  accept  advice 
decisions  (ATC  'YE')  are  mechanically  reached  under  certain  con¬ 
ditions  as  described  in  Volume  II.  The  automated  systems  also 
provide  for  automatic  generation  of  reject  advice  transactions 
when  an  offer  reply  transaction  is  not  received  from  a  SICC  within 
60  days  of  providing  an  offer  advice  transaction.  When  advice 
decisions  are  reached  on  a  manual  basis,  this  advice  must  be  input 


to  the  automated  system  to  maintain  an  audit  trail  on  the  SSR 
Suspense  File.  The  manual  advice  decision  is  reached  by  dif¬ 
ferent  functional  personnel  in  the  Services.  In  two  of  the  Ser¬ 
vices,  the  accept  decision  is  made  by  an  Item  manager  after  an 
asset  availability  check.  Generally,  reject  decisions  and  accept 
decisions  in  the  other  Services  are  reached  in  the  functional 
element  where  the  SSR  transactions  are  received.  In  one  of  these 
Services  the  initial  accept  decision  is  reviewed  by  an  item 
manager  and  may  be  changed  resulting  in  a  second  advice  transac¬ 
tion  to  the  SICC. 

The  IMM  Manual  contains  a  method  of  providing 
a  new  support  date  in  an  accept  advice  transaction  when  the  Date 
Repair  Parts  Required  (DRPR)  cannot  be  met.  The  DRPR  is  a  PDSSR 
transaction  data  element.  The  statistics  from  the  DODSSR  data 
collection  as  presented  in  Volume  III  show  a  low  percentage  of 
this  accept  advice  being  used  by  WIMMs.  During  the  operational 
review,  the  Study  Team  found  that  while  this  data  element  was 
regularly  provided  to  the  functional  element  prior  to  the  advice 
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generally  based  on  the  content  of  certain  LISSR  transaction  data 
elements  including  Activity  Code  From,  MOE  rule.  Item  Identifica¬ 
tion  Data  Receiver  and  Item  Identification  Data  Collaborator. 

In  the  Navy,  an  add  user  transaction  will  be  automatically  gener¬ 
ated  for  transmittal  to  DLSC  when  the  item  is  actively  managed 
by  the  Navy  and  the  SICC  is  not  already  registered  as  a  user. 

When  accept  advice  is  input  to  the  Air  Force  system,  cataloging 
transactions  are  automatically  generated  for  transmittal  to  CASO 
for  further  processing.  CASO  makes  the  determination  of  appro¬ 
priate  DLSC  cataloging  transactions.  In  the  Army  and  Marine 
Corps,  all  catalog  actions  are  taken  manually  and  all  resulting 
cataloging  transactions  are  manually  generated., 

d .  Out  pu  t  s 

Outputs  external  to  the  processing  activity  include 
advice  transactions,  followup  response  transactions,  and  cata¬ 
loging  transactions.  Advice  transactions  and  followup  response 
transactions  may  be  transmitted  to  the  SICC  via  AUTODIN  as  speci¬ 
fied  by  the  IMM  Manual.  However,  during  the  operational  review 
it  was  found  that  these  transactions  are  frequently  mailed  to 
the  SICC  in  the  same  package  groupings  ? n  which  the  corresponding 
LISSR  transactions  were  received.  In  addition,  some  followups 
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were  being  received  via  telephone  and  were  reaponded  to  by  tele¬ 
phone.  Catalog  transactions  generally  consist  of  add  user  actions 
and  are  transaitted  to  DLSC  (CASO  by  the  Air  Force)  via  AUTODIN. 

Internal  outputs  generally  Include  functional  outputs 
for  use  In  advice  determination  or  maintaining  manual  files  and 
inquiry  replies.  No  management  reports  showing  processing  actions 
or  statistics  on  a  cumulative  basis  are  produced.  Transactions 
to  update  local  inventory/requireaents  files  may  be  generated 
either  mechanically  or  manually.  The  Navy  produces  a  skeleton 
file  maintenance  transaction  for  items  which  require  manual  review 
and  advice  decision.  Each  file  maintenance  transaction  is  com¬ 
pleted  by  keypunching  In  the  ATC  and  other  advice  data  (new  sup¬ 
port  date,  etc).  When  these  completed  file  maintenance  trans¬ 
actions  are  input  to  the  automated  system,  the  SSR  Suspense  File 
is  updated  and  an  advice  transaction  is  automatically  generated. 
This  practice  of  performing  file  maintenance  prior  to  furnishing 
advice  appears  to  be  a  good  one  and  the  method  of  using  skeleton 
file  maintenance  transactions  seems  to  be  equally  good. 

e .  Controls 

The  various  data  elements  used  for  control  are  listed 
above  in  the  processing  subsection.  Only  three  of  these  data 
elements  are  used  universally.  Provisioning  Control  Code,  Item 
Serial  Number  and  Date  of  Request.  The  usage  and  application  of 
tne  others  vary  from  Service  to  Service. 


The  primary  internal  controls  are  followups  which  are 
automatically  generated  from  the  Service  systems.  in  the  Army 
and  Navy  these  internal  followups  are  generated  when  a  followup 
transaction  received  from  a  SICC  matches  a  LISSR  transaction  in 
the  SSR  Suspense  File,  but  there  is  no  advice  recorded  in  the 
SSR  Suspense  File.  The  Air  Force  automated  system  generates 
internal  followups  when  advice  is  not  present  for  an  item  25 
days  after  the  item  entered  the  automated  system  and  was  posted 
to  the  SSR  Suspense  File.  These  functional  followups  will  be 
generated  every  25  days  until  advice  is  posted  to  the  file. 


CIMM  SSR  Proces8ln{ 


CIMM  activities  include  TARCOM  in  the  Army,  the  four  DLA 
hardware  centers  and  GSA.  Within  the  CIMMs,  DLA  dominates  as  the 
receiver  of  the  vast  majority  of  LISSR  transactions.  At  the  time 
of  the  operational  implementation  review  only  DLA  had  implemented 
their  automated  systems  design.  The  Army  systems  design  was 
sufficiently  documented  at  that  time  to  determine  its  impact  on 
the  manual  processing  experienced  during  the  operational  imple¬ 
mentation  review  at  TARCOM.  The  GSA  automated  system  was  in  the 
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conceptual  stage  of  design  during  the  operetlonsl  implementation 
review  end  the  impact  of  this  automated  system  on  the  manual  pro¬ 
cess  described  in  Volume  II,  Part  2,  cannot  be  determined.  There¬ 
fore,  the  diacuaaion  of  CIMM  SSR  Processing  is  centered  around 
DLA  processing  actions.  The  actions  performed  by  TARCOM  and  CSA 
will  be  pointed  out  where  they  are  known  to  be  significantly 
different.  The  CIMM  processing  descriptions  in  Volume  II,  Part 
2,  are  generally  divided  into  three  segments;  one  each  for  active 
NSN  SSR  Processing,  Inactive  NSN/PSCN  SSR  Processing  and  Part 
Number  SSR  Processing.  Since  the  discussion  here  is  on  a  more 
general  basis,  all  SSR  transactions  are  grouped  together  here 
with  significant  processing  differences  among  these  types  pointed 
out  where  appropriate. 

The  Army  has  combined  automated  outgoing  SSR  transaction 
processing  and  automated  incoming  SSR  transaction  processing 
into  a  single  SSR  Application.  The  OLA  and  CSA  acting  predomi¬ 
nately  as  SSR  receivers  (CIMMa)  have  designed  their  automated 
systems  to  process  only  incoming  SSR  transactions.  DLA  has 
designed  this  processing  as  a  separate  application  under  SAMMS; 
while  CSA  has  designed  automated  SSR  processing  within  its  Cata¬ 
loging  System. 

a.  Inputs .  The  inputs  under  CIMM  processing  are  the 
same  as  those  discussed  under  WIMM  processing.  However,  part 
number  submissions  constitute  about  50X  of  the  CIMM  SSR  transac¬ 
tions  received.  Also  CIMMs  routinely  provide  offer  advice  and 
therefore  offer  replies  are  received  more  often  at  CIMM  pro¬ 
cessing  activities  than  at  WIMM  processing  activities.  DLA 
activities  were  receiving  followup  transactions  predominately 
via  AUTODIN,  while  other  activities  (both  CIMM  and  WIMM)  gener¬ 
ally  receive  followup  transactions  by  mail. 

b.  Files 

CIMMs,  like  WIMMs,  tend  to  maintain  both  automated 
and  manual  files.  In  the  Army,  the  same  types  of  files  are 
maintained  on  a  CIMM  basis  as  those  discussed  under  WIMM  SSR 
processing  above.  CSA  maintains  both  EAM  card  files  and  hard 
copy  listings  of  active  and  complete  items.  These  manual  fllea 
are  maintained  in  the  cataloging  functional  area  and  are  gener¬ 
ally  purged  two  years  after  completion  on  a  PCC  package  basia. 

The  files  maintained  by  DLA  are  somewhat  different 
from  those  maintained  by  other  activities  (both  SICCs  and  IMMs). 
Three  distinct  files  are  maintained  on  a  manual  basis.  An  EAM 
card  file  is  maintained  which  contains  the  original  SSR  transac¬ 
tions  received.  These  original  SSR  transactions  are  retained 
for  an  indefinite  period  (generally  until  tha  storage  cabinets 
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are  filled  Co  capacity  and  more  room  is  needed).  A  manual  PCC 
package  file  is  maintained  which  contains  correspondence  and 
hard  copy  listings  resulting  from  automated  processing  of  the 
items  within  the  PCC  package.  This  PCC  package  file  is  generally 
used  as  a  history  file  and  is  maintained  for  two  years  after  the 
package  is  completed.  A  separate  manual  file  is  maintained  on 
an  item  basis  while  the  item  is  being  actively  processed.  When 
each  item  is  completed  this  file  is  discarded.  DLA  maintains 
two  automated  SSR  files.  The  SSR  Suspense  File  contains  items 
being  actively  processed  and  items  are  purged  as  they  are  com¬ 
pleted.  The  automated  SSR  History  File  contains  items  passed 
from  the  SSR  Suspense  File  as  they  are  completed.  Items  are 
purged  from  the  SSR  History  File  on  a  PCC  package  basis  one  year 
after  the  last  item  within  the  package  is  completed.  The  fact 
that  the  structure,  organization,  and  contents  of  these  auto¬ 
mated  DLA  files  is  different  from  those  of  the  other  Components 
is  supported  by  the  discussions  in  Volumes  II  and  III. 

There  is  one  other  manual  file  that  was  found  during 
the  operational  review  of  DLA  activities.  A  3x5  card  file  is 
maintained  for  Part  Number  SSR  transactions  submitted  with  a 
Date  Technical  Data  to  be  Supplied.  This  file  is  periodically 
reviewed  and  used  to  followup  (by  correspondence)  to  SICCs  for 
submittal  of  promised  technical  data.  When  the  data  is  still 
not  received,  action  is  taken  by  the  DLA  IMM  to  obtain  the  data 
directly  from  the  manufacturer.  This  process  in  no  way  delays 
processing  of  the  SSR  transaction  and  appears  to  have  potential 
for  improving  the  quantity  and  quality  of  technical  data  received. 

c .  Processing 

Processing  of  incoming  SSR  transactions  is  primarily 
on  an  item  basis  in  the  automated  systems.  The  only  automated 
processing  accomplished  on  a  package  basis  is  package  validation 
and  purging  records  from  the  SSR  Suspense  File  in  the  Army  and 
SSR  History  File  in  DLA.  GSA  processing  is  performed  primarily 
anually  with  some  actions  performed  by  Punched  Card  Accounting 
achlne  (PCAM)  equipment.  The  processing  performed  by  GSA  is 
totally  on  a  package  basis  while  actions  performed  by  TARCOM  and 
DLA  seem  to  be  a  combination  of  package  and  item  processing.  For 
example,  in  DLA  the  initial  processing  of  incoming  SSR  transac¬ 
tions  until  they  are  input  to  the  automated  system  is  performed 
on  a  package  basis.  Also,  the  manual  and  automated  history  files 
are  maintained  on  a  package  basis.  The  remainder  of  the  manual 
processing  within  DLA  is  keyed  to  items  not  packages. 

The  major  events  performed  by  each  CIMM  for  Active 
NSN  SSR  transactions,  Inactive  NSN/PSCN  SSR  transactions  and 
Part  Number  SSR  transactions  were  discussed  in  Volume  II,  Part  2. 

Figure  V-5  shows  the  major  events  performed  while  processing 
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Parc  Number  SSR  transactions  by  CIMM.  This  figure  illustrates 

the  variance  in  the  sequence  in  which  major  events  are  performed 

and  in  the  number  of  times  certain  major  events  are  performed  by 
different  CIMMs.  Although  similar  figures  are  not  shown  for 
Active  NSN  SSR  transaction  processing  and  Inactive  NSN/PSCN  SSR 
transaction  processing,  a  review  of  these  major  events  from 
Volume  II,  Part  2,  shows  the  same  variances.  Note  also  the 
variance  in  the  sequence  of  major  events  as  shown  in  Figure  V-5 

as  shown  in  the  sequence  in  the  Conceptual  Systems  Model  (Pigure 

V-l). 


CIMM  PART  NUMBER  SSR  PROCESSING 
SEQUENCE  OF  MAJOR  EVENTS  BY  CIMM 


‘  Army 

DLA 

GSA 

! 

-Validation 

-File  Maintenance 

-Validation 

-Catalog  Data 

-Validation 

-Advice  Decision 

Screening 

-Advice  Decision 

-File  Maintenance 

!  -Advice  Decision 

-Method /Level  of 

-Validation 

-File  Maintenance 

Support 

-Advice  Decision 

-Catalog  Data 

-File  Maintenance 

-Method/Level  of 

Screening 

-DLSC  Screening 

Support 

i  -Advice  Decision 

-Advice  Decision 

-Catalog  Actions 

|  -File  Maintenance 

-File  Maintenance 

-Catalog  Data 

,  -Catalog  Actions 

-Advice  Decision 

Screening 

1  -Method /Level  of 

-File  Maintenance 

-Advice  Decision 

Support 

-Catalog  Actions 

-Catalog  Actions 

-Advice  Decision 

-File  Maintenance 

-File  Maintenance 

-Requirements 

Determination 
-File  Maintenance 

-Advice  Decision 
-Requirements 
Determination 

-DLSC  Screening 

Source:  Field  Research 


Figure  V-5 

The  discussion  of  major  events  that  follows  is  in  the  sequence 
shown  in  the  Conceptual  Systems  Model.  All  actions  are  discussed 
under  each  major  event  regardless  of  the  number  of  times  it  may 
appear  in  actual  processing  as  illustrated  by  Figure  V-5. 

(1)  Edit/ Validation .  This  major  event  is  performed 
on  an  automated  basis  by  TARCOM  and  DLA,  and  on  a  manual  basis 
by  GSA.  There  is  a  significant  difference  between  these  activi¬ 
ties  in  the  action  taken  when  an  invalid  condition  Is  found.  The 
automated  systems  of  DLA  and  TARCOM  are  designed  to  generate  re¬ 
ject  advice  when  an  invalid  condition  is  found.  GSA  will  attempt 
to  correct  the  invalid  data  and  continue  to  process  the  SSR  tr ans 
actions.  The  specific  data  elements  val idated /ed it ed /bypassed 
on  both  a  manual  and  an  automated  basis  as  well  as  the  automated 
validation  criteria  and  conventions  are  presented  in  Volume  III. 
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( 2 )  Catalog  Data  Screening 

This  major  event  is  performed  by  all  CIMMs. 

The  Army  automatically  screens  Its  local  TIR  file;  items  not 
matched  have  DLSC  screening  transaction  initiated  on  a  manual 
basis.  All  catalog  data  screening  replies  are  manually  pro¬ 
cessed  in  the  Army.  GSA  also  screens  local  catalog  files  first 
and  performs  DLSC  screening  only  on  those  items  not  matched  on 
local  catalog  files.  All  GSA  screening  is  manually  processed. 

The  catalog  data  screening  performed  by  DLA  is  significantly 
different  than  that  performed  by  other  CIMMs  or  by  WIMMs. 

Even  though  all  DLA  centers  maintain  a  local 
TIR  file,  SSR  items  are  screened  only  against  DLSC  files.  This 
process  is  totally  automated  in  DLA  both  in  transaction  genera¬ 
tion  and  reply  processing.  All  types  of  SSR  items  are  screened 
against  DLSC  files  includling  NSNs  ,  PSCNs  and  part  numbers. 

Part  number  items  are  screened  using  'P'  type  screening  which 
requires  entrance  of  the  Reference  Number  Format  Code,  Reference 
Number  Variation  Code  and  Reference  Number  Category  Code  from  the 
SSR  transaction.  Screening  replies  are  mechanically  processed 
resulting  in  Advice  Decisions  and  Catalog  Actions. 

( 3 )  Method/Level  of  Support. 

The  time  at  which  this  major  event  is  performed 
in  relation  to  other  major  events  is  significantly  different  among 
IMMs.  Note  in  Figure  V-5  that  this  major  event  is  performed  prior 
to  Catalog  Data  Screening  in  DLA  and  GSA,  while  in  TARCOM  it  is 
processed  much  later  in  the  processing  sequence.  TARCOM  and  GSA 
perform  this  major  event  manually.  An  item  manager  makes  this 
determination  in  TARCOM  using  the  Replenishment  Quantity,  Retail 
Quantity,  and  Unit  of  Issue.  GSA  generally  assigns  AAC  -  'J'  tc 
all  provisioning  SSR  items  as  a  matter  of  policy. 

DLA  determines  the  method/level  of  support  on 
an  automated  basis  using  the  AAC  recommended  in  the  SSR  transac¬ 
tion,  the  Source  Code,  the  Replenishment  Quantity,  Production 
Lead  Time  and  Unit  Price.  The  method/level  of  support  is  deter¬ 
mined  using  a  filtering  technique.  For  certain  essential  weapons 
systems,  arrangements  may  be  made  with  DLA  to  bypass  part  of  this 
filter  and  to  stock  items  as  an  NSO  item  when  they  do  not  meet 
the  criteria  for  stockage  based  on  demand.  This  bypass  is 
accomplished  using  PCC/ACF  combinations,  not  the  Weapon  System 
Code  in  the  PDSSR  transaction. 

(4)  Requirements  Determination.  As  shewn  in  Figure 
V-5,  this  major  event  is  not  performed  by  GSA  which  means  that 
GSA  does  not  initiate  procurement  action  or  forecast  requirements 
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based  on  SSR  quantities.  In  the  Army  this  major  event  is  per¬ 
formed  by  the  item  manager  as  discussed  under  WIMM  SSR  processing 
above.  Within  DLA,  SSR  quantities  are  passed  to  the  requirements 
subsystem  as  the  final  processing  event  for  items  on  which  sup¬ 
port  is  accepted  and  which  are  determined  to  be  stocked  items. 

The  requirements  subsystem  produces  functional  outputs  for  review 
by  item  managers. 

(5)  File  Maintenance 


as  a  CIMM  are 
cussed  above, 
data  elements 
GSA  files  and 


The  file  maintenance  actions  performed  by  TARCOM 
similar  to  those  performed  by  Army  as  a  WIMM  dls- 
These  actions  are  not  repeated  here.  The  SSR 
generally  used  for  sequencing  and  control  of  manual 
both  manual  and  automated  files  in  DLA  include: 


*  Activity  Code  From 

*  Provisioning  Control  Code 

*  Item  Serial  Number 

*  Date  of  Request 


Not  all  of  these  data  elements  are  used  for  all  SSR  files  and 
the  sequence  in  which  these  data  elements  are  used  varies  from 
file  to  file. 


Unlike  WIMM  files,  there  are  generally  separate 
files  maintained  for  active  items  and  completed  items  by  CIMMs. 
However,  the  manual  files  maintained  tend  to  be  more  complete 
than  the  automated  files.  A  good  example  of  this  is  the  files 
maintained  by  DLA.  The  automated  files  contain  records  on  most 
invalid  SSR  transactions  and  all  valid  SSR  transactions  except 
change  SSR  transactions.  Only  superseding  change  SSR  transac¬ 
tions  are  posted  to  automated  SSR  files.  Manual  SSR  files 
(particularly  the  PCC  file)  contain  records  of  all  SSR  transac¬ 
tions  received  including  valid  and  invalid  SSR  transactions  and 
change  SSR  transactions. 

In  GSA,  two  types  of  file  maintenance  actions 
exist.  The  first  is  establishing  Incoming  SSR  transactions  in 
manual  files.  The  second  action  is  posting  SSR  advice  to  each 
item  in  the  file.  This  second  file  maintenance  action  may  be 
posting  of  initial  advice  or  final  advice;  and  when  the  advice 
is  final  (e.g.  NSN  Notification),  it  is  generally  the  final 
action  taken  relative  to  SSR  processing. 

File  maintenance  actions  occur  several  times 
during  DLA  processing  as  shown  in  Figure  V-S.  The  first  file 
maintenance  action  is  establishing  a  manual  PCC  fodder  for  the 
incoming  package.  After  validation,  most  invalid  SSR  transac¬ 
tions  and  all  valid  SSR  transactions  are  posted  to  the  automated 
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SSR  Files.  Invalid  SSR  transactions  have  the  reject  advice 
posted  to  the  manual  PCC  files  and  valid  SSR  transactions  have 
DLSC  screening  transactions  mechanically  generated  for  AUTODIN 
submittal.  When  DLSC  replies  result  in  an  advice  decision,  this 
advice  is  posted  to  the  automated  SSR  files  and  to  the  manual 
PCC  file.  At  this  point  matched  PSCNs  and  unmatched  Part  Numbers 
are  output  for  manual  review.  This  manual  review  is  conducted 
on  an  item  basis  and  results  in  accept,  offer,  or  reject  advice. 
This  advice  is  input  to  the  automated  system  using  file  mainte¬ 
nance  transactions  which  update  the  automated  SSR  files  and 
result  in  updating  of  the  manual  PCC  file.  When  NSN  assignments 
are  received  from  DLSC,  the  automated  SSR  files  are  again  updated 
and  the  manual  PCC  file  is  also  updated.  When  SSR  change  trans¬ 
actions  are  received  they  are  Hated  after  validation  and  this 
list  is  placed  in  the  manual  PCC  file.  As  mentioned  above,  only 
superseding  item  changes  are  posted  to  automated  SSR  files.  So 
it  may  be  seen  that  while  file  maintenance  actions  occur  several 
times  during  the  SSR  processing  cycle,  they  generally  serve  to 
post  new  items  to  these  files  or  post  advice  to  these  files. 

Inquiries  to  the  automated  SSR  files  in  DLA 
are  processed  as  file  maintenance  actions.  These  inquiries  are 
input  as  file  maintenance  transactions  and  may  request  informa¬ 
tion  on  an  item  or  a  PCC  basis.  Inquiry  transactions  are  first 
matched  against  the  SSR  Suspense  File.  When  the  inquiry  is  for 
an  item  and  the  Information  is  located  on  the  SSR  Suspense  File, 
the  information  is  output  for  printing  and  the  inquiry  process 
ends.  When  the  item  is  not  found  on  the  SSR  Suspense  File,  the 
inquiry  then  is  passed  to  the  weekly  processing  cycle  for  match¬ 
ing  against  the  SSR  History  File.  Inquiries  requesting  Informa¬ 
tion  on  a  PCC  basis  are  matched  to  both  the  SSR  Suspense  File 
and  the  SSR  History  File. 

Followup  transactions  received  from  SICCs  are 
also  processed  as  file  maintenance  actions.  In  GSA, followup 
transaction  processing  is  totally  manual,  while  in  DLA  this 
processing  is  totally  automated.  When  followup  transactions  are 
received  by  GSA,  the  SSR  History  files  are  first  checked  to 
determine  if  advice  has  been  determined  and,  if  so,  this  same 
advice  is  returned  in  a  followup  response  transaction.  When  the 
item  cannot  be  located  in  the  SSR  History  File,  when  the  active 
file  is  checked  to  determine  the  processing  status  of  the  item. 
When  the  item  is  still  being  processed  within  GSA  (advice  has 
not  been  determined)  pending  advice  is  returned  on  the  followup 
response  transaction.  When  the  item  cannot  be  located,  the 
followup  response  transaction  contains  an  ATC  '36'  (Other). 

This  is  a  significant  variation  from  other  IMMs  who  generally 
use  ATC  '66'  (No  Record)  when  a  item  is  not  found  in  IMM  files. 
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Followup  transactions  received  by  DLA  are  Input 
to  the  automated  system  for  processing  either  directly  when  re¬ 
ceived  via  AUTODIN  or  manually  when  received  by  mail.  The  auto¬ 
mated  system  matches  the  followup  to  the  SSR  Suspense  File  first 
and,  if  found,  generates  a  followup  response  transaction  based 
on  the  advice  in  the  file  record.  When  no  advice  has  been  posted 
to  the  file  record,  pending  advice  is  used  in  the  followup  response 
transaction.  When  the  item  is  not  located  on  the  SSR  Suspense 
File,  the  followup  transaction  is  passed  to  the  weekly  processing 
cycle  for  matching  against  the  SSR  History  File.  Items  not  found 
in  the  SSR  History  File  have  followup  response  transactions  gener¬ 
ated  containing  "no  record"  advice. 

There  is  one  other  type  of  followup  within  the 
DLA  system  which  warrants  discussion.  This  type  of  followup  was 
not  found  by  the  study  team  in  any  other  Component  automated 
systems  design  nor  was  it  being  manually  generated  at  any  of  the 
other  Component  activities  visited.  When  offer  advice  is  returned 
to  SICCs  by  DLA,  the  automated  SSR  system  sets  up  a  suspense  within 
the  item  record.  When  an  offer  reply  transaction  has  not  been 
received  within  30  days  from  the  date  of  the  offer  advice  a  list¬ 
ing  is  generated  relating  this  fact  to  functional  personnel. 

When  an  offer  reply  transaction  has  not  been  received  after  45 
days  a  second  listing  is  generated.  The  receipt  of  an  offer 
reply  transaction  cancels  this  suspense.  These  listings  are 
produced  to  be  mailed  to  the  SICCs  reminding  them  that  an  offer 
reply  must  be  submitted  to  avoid  rejection  of  the  item.  It  must 
be  noted  that  in  the  procedures  in  effect  prior  to  implementa¬ 
tion  of  the  IMM  Manual,  this  type  of  followup  was  documented. 

This  concept  of  following  up  for  a  reply  to  offer  advice  has 
merit  and  should  be  considered  for  automation  both  in  terms  of 
generation  and  transmittal  by  all  IMMs  as  a  standard  procedure. 

( 6 )  Advice  Decision 


This  major  event  is  accomplished  by  the  Army  as 
a  CIMM  in  the  same  manner  as  described  for  the  Army  under  WIMM 
SSR  processing  above.  However,  there  are  two  significant  dif¬ 
ferences  worth  noting.  First,  since  TARCOM  as  a  CIMM  must  sup¬ 
port  items  assigned,  Part  Number  SSR  transactions  cannot  be 
routinely  rejected  as  they  are  by  WIMMs.  This  requires  TARCOM 
to  perform  item  entry  control  for  these  part  number  items  and 
results  in  generation  of  offer  advice  to  the  SICCs.  The  Army 
automated  SSR  system  is  designed  to  suspense  these  offer  advices 
and  when  an  offer  reply  is  not  received  within  60  days,  a  reject 
advice  transaction  is  automatically  generated  for  transmittal  to 
the  SICC  containing  ATC  '08'  (No  Reply  to  Offer).  The  second 
processing  action  is  consideration  of  the  accept  advice  and  sup¬ 
port  date.  As  discussed  in  Volume  II,  generally  when  items 
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reach  Che  Item  manager  for  processing  they  have  already  been 
accepted  for  support*  The  TARCOM  item  manager  reviews  the  SSR 
transaction  quantities  and  unit  of  issue  in  conjunction  with 
existing  local  records  on  the  item  to  determine  the  applicable 
accept  advice  ATC.  The  TARCOM  item  manager  also  reviews  the 
Production  Leadtime  and  DRPR  from  the  SSR  transaction  to  deter¬ 
mine  if  a  support  date  need  be  provided  the  SICC,  and  if  so, 
what  that  support  date  should  be.  After  these  determinations 
are  made*  the  item  is  forwarded  to  the  functional  area  respon¬ 
sible  for  providing  the  advice  to  the  SICC. 

All  advice  decisions  within  GSA  are  made  on  a 
manual  basis.  For  NSN  SSR  transactions,  the  advice  is  generally 
accept  (provided  it  is  an  item  managed  by  GSA  as  determined  from 
catalog  data  screening).  When  catalog  data  screening  indicates 
the  item  is  managed  by  another  IMM,  the  item  is  rejected.  When 
catalog  data  screening  or  item  entry  control  identifies  a  stan¬ 
dard  item,  replacement  item  or  an  existing  NSN  for  a  part  number, 
these  are  generally  transmitted  to  the  SICC  as  offer  advice,  even 
though  current  SSR  Procedures  specify  a  reject  for  this  condition. 
GSA  also  rejects  SSR  transactions  using  ATC  '08'  when  offer  replie 
are  not  received  within  60  days;  however,  the  suspense  and  review 
is  on  a  manual  basis  within  GSA.  GSA  generally  does  not  review 
SSR  transactions  for  determination  of  a  new  support  date  due  to 
the  almost  exclusive  use  of  ATC  'YD'  (Centrally  Procure  on  Demand) 

DLA's  automated  system  is  designed  to  make  many 
more  advice  decisions  than  the  other  Component  systems.  Gener¬ 
ally  reject  advice  decisions  based  on  invalid  data  are  made  on 
an  automated  basis  as  part  of  all  Component  automated  system 
designs.  The  significant  difference  is  in  the  automated  advice 
decisions  made  from  DLSC  screening  results.  As  described  above, 
other  IMMs  generally  process  all  screening  replies  on  a  manual 
basis.  DLA  performs  several  actions  on  an  automated  basis.  It 
is  this  automated  processing  of  DLSC  replies  that  distinguishes 
the  DLA  automated  system  from  the  other  Components'  automated 
systems.  NSN  screening  replies  are  analyzed  to  determine  the 
manager,  AAC  and  other  data.  When  the  screening  indicates  DLA 
is  the  manager,  an  accept  advice  transaction  is  automatically 
generated  for  transmittal  to  the  SICC.  The  accept  advice  ATC 
for  these  items  as  well  as  other  accepted  items  discussed  below 
is  determined  on  an  automated  basis.  The  automated  system 
determines  an  AAC  for  each  SSR  item  as  discussed  under  Method/ 
Level  of  Support  above.  This  AAC  is  compared  to  that  received 
in  the  DLSC  reply  and  the  highest  level  is  used  to  determine  the 
ATC  to  be  used  in  the  accept  advice  transaction.  The  automated 
system  also  performs  a  support  date  determination  using  the 
PLT  and  DRPR  as  described  in  Volume  III.  The  new  support  date 
determination  and  the  AAC  are  used  to  determine  the  ATC  to  be 
returned  to  the  SICC.  When  an  NSN  is  not  matched  in  DLSC 
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files  or  the  NSN  is  managed  by  another  IMM,  cancelled,  etc.; 
reject  advice  transactions  are  automatically  generated  for  these 
conditions.  When  part  number  screening  replies  indicate  a  match 
to  an  NSN  in  DLSC  files,  reject  advice  transactions  are  automati¬ 
cally  generated  for  these  items.  Advice  decisions  are  made 
manually  for  PSCNs  matched  to  DLSC  files  and  Part  Numbers  not 
matched  to  DLSC  files.  Manual  advice  is  generally  either  accept 
or  offer.  The  reject  advice  determined  on  a  manual  basis  is 
usually  limited  to  lack  of  technical  data.  As  with  the  other 
Component  automated  systems  DLA  suspenses  offer  advice  for  60 
days  and  when  a  reply  is  not  received  a  reject  advice  (ATC  '08') 
transaction  is  automatically  generated.  In  addition  when  an  NSN 
assignment  for  an  SSR  transaction  submitted  with  a  part  number 
is  received  from  DLSC,  the  NSN  is  passed  to  the  SSR  system  which 
automatically  generates  an  NSN  Notification  transaction. 

( 7 )  Catalog  Actions 


Within  the  Army,  TARCOM  as  a  CIMM,  generates 
catalog  actions  on  a  manual  basis.  The  catalog  actions  most 
often  used  include  add  user  actions  and  NUN  requests.  The  auto¬ 
mated  system  design  in  the  Army  provides  for  automatic  generation 
of  add  user  transactions  for  activities  submitted  on  additional 
user  transactions.  GSA  as  a  manually  oriented  activity  gener¬ 
ates  all  catalog  actions  manually. 

Catalog  actions  are  generated  as  a  combination 
of  manual  and  automated  actions  within  DLA.  Many  catalog  actions 
resulting  from  SSR  processing  are  produced  mechanically.  These 
include  the  generation  of  add  user  transactions  for  the  SSR  sub¬ 
mitter  and  the  activities  included  in  additional  user  transac¬ 
tions,  generation  of  cataloging  transactions  to  reactivate  in¬ 
active  NSNs,  and  updating  of  DLSC  catalog  management  data  such 
as  upgrading  of  the  level  of  support  ( AAC ) .  Additional  reference 
numbers  submitted  with  LISSR  transactions  require  manual  review 
and  generation  of  DLSC  add  reference  number  transactions.  NIIN 
assignment  requests  to  DLSC  are  partially  generated  on  an  auto¬ 
mated  basis  and  partially  generated  on  a  manual  basis.  The 
request  data  generated  mechanically  include  Segments  B  and  H 
which  are  developed  using  SSR  data  elements;  e.g., 

*  Activity  Code  From 

*  Additional  User  Activity  Codes 

*  AAC  (Recommended  or  as  determined) 

*  Unit  of  Issue 

*  Unit  Price 

*  Shelf  Life  Code 

Other  request  data  must  be  manually  generated  using  submitted 
technical  data;  e.g.,  item  name  and  FSC  from  item  name  transac¬ 
tion  when  submitted. 
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d .  Outputs 

CIMM  activities  produce  both  external  and  internal 
outputs.  Generally  external  outputs  include  advice  transactions 
followup  response  transactions  and  cataloging  transactions. 
Advice  and  followup  response  transactions  are  transmitted  to 
SICCs  using  mail  or  AUTODIN.  DLA  uses  predominantly  AUTODIN, 
while  other  IMMs  use  predominantly  mail.  Cataloging  transac¬ 
tions  are  generally  transmitted  to  DLSC  using  AUTODIN.  DLA  pro¬ 
duces  one  other  external  output  in  the  form  of  30  and  45  day 
offer  reply  followups.  These  hard  copy  listings  are  mailed  to 
the  appropriate  SICCs. 

Internal  outputs  include  functional  listings  and 
skeleton  file  maintenance  cards  (DLA  only)  for  use  in  advice 
determination,  updating  manual  files  and  providing  advice  to  the 
automated  system.  There  are  no  cumulative  management  reports 
produced,  although  some  statistics  are  accumulated  and  output 
on  a  cyclic  basis.  Transactions  to  update  local  files  (e.g., 
requirements  files)  may  be  generated  on  a  manual  or  automated 
basis.  The  DLA  concept  of  using  file  maintenance  transactions 
is  similar  to  that  described  for  the  Navy  under  WIMM  SSR  pro¬ 
cessing  above  and  has  the  same  advantages.  The  inquiry  results 
received  from  the  DLA  automated  system  are  significantly  dif¬ 
ferent  from  those  received  from  other  Component  systems.  The 
DLA  system  provides  a  formatted  response  which  includes  only 
basic  information;  such  as,  control  elements,  item  identifier, 
advice  (ATC),  NSN  assigned,  etc.  This  type  of  inquiry  response 
is  not  sufficient  for  functional  personnel  to  determine  why  cer¬ 
tain  actions  are  taken  and  whether  or  not  those  actions  are 
appropriate . 

e .  Controls 

Controls  used  by  the  Array  as  a  CIMM  are  the  same  as 
those  used  by  the  Army  when  acting  as  a  WIMM  and  are  discussed 
under  WIMM  SSR  Processing  above.  The  primary  control  within  GSA 
is  the  manual  file  maintained  for  active  items.  This  file  Is 
monitored  for  completion  of  SSR  transactions  and  receipt  of 
offer  reply  transactions.  When  advice  has  not  been  determined 
25  days  after  receipt,  a  pending  advice  transaction  is  manually 
generated  and  mailed  to  the  SICC.  When  an  offer  reply  has  not 
been  received  within  60  days  of  advice,  a  reject  advice  transac¬ 
tion  containing  ATC  '08'  is  manually  generated  and  mailed  to  the 
SICC. 


DLA  has  both  manual  and  automated  controls  built 
into  its  system.  The  primary  manual  control  is  the  manual  3x5 
card  file  maintained  for  items  on  which  technical  data  was  pro¬ 
mised,  but  not  submitted.  This  file  is  used  as  a  control  for 


following  up  to  the  SICC  for  submittal  of  this  promised  data. 

The  automated  system  takes  care  of  the  25  day  pending  advice  and 
no  reply  to  offer  reject  advice  handled  manually  by  GSA  as  des¬ 
cribed  above.  The  DLA  automated  system  also  produces  a  func¬ 
tional  overage  report  as  a  controlling  feature.  Items  appear  on 
this  report  at  three  stages.  An  item  appears  on  Part  I  of  this 
report  when  it  has  been  on  the  SSR  Suspense  File  for  12  days 
without  advice  determination.  When  the  25  day  initial  advice 
limit  is  reached  or  in  the  case  of  part  numbers  awaiting  NUN 
assignment,  items  appear  on  Part  II  of  this  Report.  Items  appear 
on  Part  III  of  this  Report  when  advice  is  overdue.  This  Report 
is  used  by  functional  personnel  to  expedite  processing  of  these 
items,  particularly  those  appearing  in  Part  III. 

F.  SICC  SSR  ADVICE  PROCESSING  PHASE 


This  processing  phase  begins  upon  receipt  of  advice  transac¬ 
tions  or  followup  response  transactions  by  the  SICC  from  IMMs. 
Processing  is  accomplished  in  this  phase  on  an  item  basis  by  all 
SICCs.  Followup  response  transactions  are  processed  as  advice 
transactions  by  all  SICCs. 

1.  Input .  The  inputs  to  this  processing  phase  include 
accept  advice  transactions,  offer  advice  transactions,  reject 
advice  transactions,  NSN  notification  transactions,  followup 
response  transactions  and  associated  technical  data.  The  trans¬ 
actions  may  be  received  by  mail  or  by  AUTODIN.  The  technical 
data  is  received  by  mail  and  consists  of  returned  technical  data 
for  items  rejected  by  the  IMM  or  technical  data  (e.g.,  DLA  Form 
546)  furnished  with  an  offer  advice  transaction. 

2.  Files .  The  files  used  in  this  processing  phase  are  the 
same  files  discussed  In  the  Provisioning  Processing  Phase  and 
SICC  SSR  Processing  Phase  above. 

3.  Processing .  Both  manual  and  automated  processing  in 
this  phase  is  done  on  an  item  basis  by  all  SICCs;  however,  the 
processing  actions  done  manually  versus  those  performed  mechani¬ 
cally  varies  from  Service  to  Service.  In  addition,  followup 
response  transactions  are  generally  processed  as  advice  transac¬ 
tions  and  will  not  be  discussed  separately.  The  Conceptual 
Systems  Model  shows  this  processing  phase  consisting  of  three 

ma  jor  events. 

*  File  Maintenance 

*  Advice  Review 

*  Notification  Actions 

During  the  operational  review  the  study  team  found  that  not  all 
SICCs  performed  all  of  these  major  events  and  that  some  SICCs 
performed  additional  actions.  These  findings  are  illustrated 
in  Figure  V-6 . 
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SICC  SSR  ADVICE  PROCESSING  PHASE 
SEQUENCE  OF  MAJOR  EVENTS  BY  SICC 


-File  Mainte¬ 
nance 

-Catalog  Data 
Screening 
-Advice  Review 


-File  Mainte¬ 
nance 

-Advice  Review 
-File  Mainte- 


Air  Force _ 

-Validation 
-File  Mainte¬ 
nance 

-Advice  Review 
-Notif ication 
Actions 
-File  Mainte- 


Marlne  Corps 

-File  Mainte¬ 
nance 

-Advice  Review 
-File  Mainte¬ 
nance 

-Notification 

Actions 


Source:  Field  Research 


Figure  V-6 


This  figure  shows  the  variation  in  both  the  major  events  per¬ 
formed  by  the  different  SICCs  and  the  variation  in  the  sequence 
in  which  they  are  performed.  Because  of  the  variation  in  number 
and  sequence  of  major  events  among  the  SICCs,  each  major  event 
will  be  discussed  below  in  the  following  order: 

*  Validation 

*  File  Maintenance 

*  Catalog  Data  Screening 

*  Advice  Review 

*  Notification  Actions 


SSR  advice  transactions  are  generally  received  in  the  functional 
area  which  has  the  responsibility  for  mailing  outgoing  SSR  trans¬ 
actions  to  IMMs.  The  advice  transactions  are  usually  initially 
processed  by  this  functional  element  and,  when  required,  subsequent 
actions;  i.e.,  SSR  resubmittal,  are  performed  here. 

a.  Validation.  During  the  operational  review  only  the 
Air  Force  was  validating  incoming  advice  transactions.  This 
validation  is  performed  on  an  automated  basis  in  the  Air  Force 
automated  SSR  system.  The  SSR  systems  designs  of  the  Army  and 
Navy  also  provide  for  automated  validation  of  incoming  advice 
transactions.  Although  the  particular  validation  criteria  and 
conventions  are  discussed  in  Volume  III,  there  are  two  key  points 
in  this  major  event  repeated  here.  First,  a  key  portion  of  this 
validation  is  a  match  on  control  elements  (which  vary  by  Service) 
to  a  LISSR  transaction  on  the  SSR  Suspense  File.  Second,  if  an 
invalid  condition  on  an  advice  transactions  is  found,  there 
currently  is  no  wr'  provided  by  the  IMM  Manual  for  communicating 
this  to  the  IMM.  is  has  led  to  development  of  Service  unique 
error  codes  for  internal  use  as  discussed  in  Volume  III. 
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b.  File  Maintenance.  This  major  event  generally  con¬ 
sists  of  posting  advice  to  the  automated  and  manual  files  main¬ 
tained  by  SICCs.  In  the  Navy,  when  an  offer  is  posted  to  the 
SSR  Suspense  File,  a  skeleton  file  maintenance  transaction  is 
automatically  generated  for  functional  use.  This  file  mainte¬ 
nance  transaction  is  designed  to  be  completed  by  functional  per¬ 
sonnel.  The  accept  or  reject  decision  is  to  be  entered  in  the 
file  maintenance  transaction  which  is  then  to  be  input  to  the 
automated  system  which  will  post  the  accept  or  reject  decision 
to  the  SSR  Suspense  File  and  generate  offer  reply  transactions 
to  be  returned  to  the  IMM.  The  Navy  and  Air  Force  systems  set 
up  suspenses  which  generate  internal  followups  when  not  met. 
These  followups  and  suspenses  are  discussed  in  the  controls  sub¬ 
section  below. 


c.  Catalog  Data  Screening.  This  major  event  is  per¬ 
formed  only  by  the  Army  and  is  a  totally  manual  process.  The 
stated  purpose  of  performing  catalog  data  screening  when  accept 
advice  is  received  is  to  verify  that  the  IMM  took  proper  actions 
to  add  Army  as  a  user  of  the  item.  It  also  is  used  to  obtain 
the  assigned  NSN  for  part  number  SSR  items  earlier  than  receipt 


by  NSN  notification  transaction  under  the  SSR  system. 


d.  Advice  Review.  The  advice  review  performed  varies 
distinctly  depending  on  whether  the  advice  is  accept,  reject  or 
offer.  Therefore,  each  of  these  categories  are  discussed  sepa¬ 
rately.  However,  it  must  be  noted  that  technical  data  must  be 
returned  by  IMMs  for  Part  Number  SSR  submittals  rejected  and 
must  be  provided  with  offer  advice  transactions.  When  the  offer 
advice  transactions  are  transmitted  via  AUTODIN  and  the  technical 
data  mailed,  the  SICC  must  wait  for  the  arrival  of  the  technical 
data  before  the  advice  review  can  be  performed. 

(1)  Accept  Advice.  This  type  of  advice  is  given  a 
cursory  review  and  is  used  primarily  in  conjunction  with  NSN 
notification  transactions  to  complete  processing  of  SSR  items. 
When  accept  advice  is  posted  to  the  SSR  Suspense  File  in  the 
Navy,  listings  are  generated  for  items  assigned  ACC  'J'  by  the 
IMM  and  items  which  could  not  be  supported  by  the  DRPR.  The 
functional  user  may  then  take  appropriate  action  to  initiate 
requisitions  for  items  on  the  AAC  'J'  listing  and  to  purchase 
part  or  all  of  the  retail  quantity  from  the  end  item  contractor 
for  items  which  could  not  be  supported  by  the  DRPR. 

(2)  Reject  Advice.  Reject  advice  is  reviewed  to 
determine  if  the  reject  is  caused  by  a  validation  error,  impro¬ 
per  management  or  technical  data  on  the  LISSR  transactions,  or  a 
support  reject  based  on  improper  IMC  coding,  etc.  The  functional 
element  receiving  the  advice  transaction  generally  determines 

the  correct  entry  for  invalid  data  rejects  and  generates  SSR 


resubmission  transactions.  These  are  mailed  to  the  IMM,  after 
automated  validation  and  posting  to  the  SSR  Suspense  Pile.  When 
a  reject  is  received  due  to  improper  data,  other  functional  per¬ 
sonnel  (cataloger,  equipment  specialist,  provisioner,  etc.)  may 
be  contacted  to  provide  the  correct  data  for  SSR  resubmission 
transactions.  Generally,  when  a  support  reject  is  received,  the 
SICC  must  become  the  IMM  for  the  item.  When  this  occurs  in  the 
Air  Force,  the  item  is  returned  to  the  provisioner  and  a  file 
maintenance  transaction  is  manually  generated  to  delete  the  item 
from  the  SSR  Suspense  File.  The  Air  Force  automated  system  auto¬ 
matically  processes  some  reject  transactions.  These  reject  advlc 
transactions  are  posted  to  the  SSR  Suspense  File  and  SSR  resub¬ 
missions  are  automatically  generated  for  mailing  to  the  appropri¬ 
ate  IMM.  The  specific  rejects  ATCs  automatically  processed  are 
described  in  Volume  II,  Part  1,  but  generally  include  cases  where 
a  part  number  or  nonstandard  item  was  submitted  and  the  IMM 
matched  the  Part  Number  to  an  NSN  in  DLSC  files.  In  this  case 
the  IMM  returns  the  matched  NSN  in  the  reject  advice  transaction 
and  the  Air  Force  generates  an  NSN  SSR  transaction  for  resubmit¬ 
tal. 

(3)  Offer  Advice.  The  Air  Force  has  an  established 
procedure  for  processing  offer  advice  transactions  which  is 
significantly  different  from  the  action  taken  by  other  SICCs. 

In  the  Air  Force  offer  advice  transactions  and  technical  data 
are  forwarded  directly  to  CASO,  the  central  cataloging  activity 
for  the  Air  Force,  for  processing.  A  copy  of  the  advice  trans¬ 
action  is  sent  to  the  SSR  submitter.  The  accept  or  reject  deci¬ 
sion  is  made  at  CASO,  and  CASO  generates  offer  reply  transactions 
to  the  IMM.  CASO  also  provides  the  provisioning  ALC  with  a  noti¬ 
fication  of  the  accept/re ject  decision.  At  other  SICCs,  the 
accept/re ject  decision  is  generally  made  by  provisioning  or  equip 
ment  specialist  personnel  at  the  SICC  activity.  Offer  reply 
transactions  are  then  generated  at  the  SICC  activity  and  trans¬ 
mitted  to  the  IMMs. 

(4)  No  Record  Advice.  When  a  followup  response 
transaction  is  received  by  a  SICC  indicating  the  IMM  has  no 
record  of  receiving  the  original  SSR  transactions,  the  SICC 
generally  regenerates  the  original  SSR  using  a  new  DOR  and  mails 
it  to  the  IMM  for  processing.  This  regeneration  is  done  on  an 
automated  basis  by  the  Navy  and  Air  Force,  and  manually  in  the 
Army  and  Marine  CorpB. 


e.  Notification  Actions.  Except  for  the  provisioning 
system/SSR  system  interface  in  the  Air  Force,  notification 
actions  are  generally  performed  on  a  manual  basis.  When 
received  on  an  offered  item  is  accepted  by 


advice 
a  support  reject 
the  provisioning 


the 


accept 
SICC  or 

advice  is  received,  the  functional  area  within 
activity  responsible  for  fielding  the  end  item 


is  notified  using  a  listing  showing  the  item  and  the  advice. 

This  functional  area  uses  the  notification  to  update  provision¬ 
ing  and  local  catalog  files  and  to  initiate  other  actions  when 
necessary . 

4 .  Outputs 

Outputs  produced  for  external  use  or  transmittal  consist 
of  offer  reply  transactions  and  SSR  resubmittals.  These  trans¬ 
actions  are  generally  mailed  to  the  IMM  for  processing. 

Outputs  produced  for  internal  use  generally  consist  of 
functional  listings.  Cumulative  management  reports  are  not 
produced;  however,  some  cyclic  statistics  are  produced  such  *s 
number  of  reject  advices  received  during  the  cycle,  etc.  As 
discussed  above,  the  Navy  automated  system  generates  skeleton 
file  maintenance  transactions  for  use  in  replying  to  offer 
advice  transactions. 

5.  Controls .  The  controls  used  in  this  processing  phase 
generally  parallel  those  used  in  the  SICC  SSR  processing  phase 
discussed  above.  There  are  certain  automated  controls  used  by 
the  Navy  and  Air  Force  in  this  processing  phase  which  require 
discussion.  Both  the  Navy  and  Air  Force  maintain  an  automated 
suspense  for  generation  of  SSR  resubmittals  when  reject  advice 
is  received.  This  suspense  varies  from  30  days  to  40  days; 
however,  both  systems  generate  functional  followups  when  the  SSR 
resubmi t ta.ls  have  not  been  input  to  the  automated  system  within 
the  suspense  period.  The  Air  Force  automated  system  also  main¬ 
tains  a  15-day  suspense  for  offer  advice  transactions.  Again 
when  an  offer  reply  transaction  has  not  been  input  to  the  auto¬ 
mated  system  within  15  days  of  receipt  of  the  offer  advice  a 
functional  followup  is  generated.  These  resubmittal  suspenses 
were  determined  by  the  respective  Services  since  the  IMM  Manual 
contains  no  standards  or  goals  in  this  area. 

G.  NONPROVISIONING  SSR  PROCESSING 


The  processing  of  nonprovisioning  items  parallels  that  of 
provisioning  items  in  terms  of  actions  and  major  events.  There 
are  areas  where  important  processing  differences  do  exist.  These 
differences  lie  primarily  in  how  nonprovisioning  items  are  ini¬ 
tiated,  the  events  performed  manually  versus  those  performed  by 
an  automated  system,  and  the  assignment  of  certain  control  data 
elements.  There  are  differences  in  IMM  processing  actions  and 
SICC  SSR  advice  processing  actions  which  will  also  be  discussed. 

1 .  Nonprovisioning  Processing  Phase 

While  all  provisioning  SSR  items  originate  from  the  pro¬ 
visioning  process,  nonprovisioning  SSR  items  emanate  from  several 
sources  which  vary  from  Service  to  Service.  There  is  one  source 
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common  to  the  Services.  Item  recommendations  from  field  activi¬ 
ties  generally  become  nonprovisioning  SSR  candidates  in  each 
Service  except  when  the  Service  already  manages  the  item.  Other 
sources  vary  from  Service  to  Service,  but  include  follow-on  and 
r e pro vis ioning  efforts,  items  determined  to  be  nonsupport  items 
during  the  provisioning  process  but  subsequently  needed  for  sup¬ 
port,  and  items  which  enter  the  Service  system  thrcugh  processes 
other  than  the  provisioning  process. 

The  processing  performed  on  nonprovisioning  items  is 
performed  manually  in  this  processing  phase,  while  many  provi¬ 
sioning  item  actions  in  this  processing  phase  are  automated. 

There  is  no  automated  system  for  processing  nonprovisioning  items 
equivalent  to  the  automated  systems  that  exist  for  processing 
provisioning  items,  and  nonprovisioning  items  generally  are  not 
input  to  the  automated  provisioning  system.  In  addition,  require 
ments  computations  are  usually  performed  manually  by  an  item 
manager  for  nonprovisioning  items,  while  the  Army  and  Navy  SICCs 
have  automated  requirements  computation  applications  used  for 
provisioning  items . 

SSR  generation  criteria  for  non provis ioning  items  la 
generally  the  same  as  the  SSR  generation  criteria  for  provision¬ 
ing  items.  However,  there  is  one  significant  difference  in  this 
criteria  for  nonprovisioning  items.  This  difference  is  the  use 
of  IMC  adopt  transactions  in  lieu  of  SSR  transactions  for  nonpro¬ 
visioning  items  for  which  NSNs  exist.  These  IMC  adopt  transac¬ 
tions  are  used  by  the  Air  Force  and  Marine  Corps,  but  not  by  the 
Army  and  Navy. 

The  two  most  important  control  data  elements  are  assigned 
significantly  different  for  provisioning  SSR  items  versus  those 
for  nonprovisioning  SSR  items.  These  data  elements  are  PCC  and 
ISN.  These  control  data  elements  are  generally  assigned  in  the 
provisioning  documentation  early  in  this  processing  phase  for 
provisioning  items,  while  for  nonprovisioning  items,  these  data 
elements  are  generally  assigned  in  the  SICC  SSR  processing  phase. 
There  is  also  a  significant  difference  in  how  these  data  ele¬ 
ments  are  assigned.  In  the  provisioning  process,  a  single  PCC 
is  usually  assigned  to  a  single  end  item/weapon  system/provision¬ 
ing  list  and  the  PLISN  from  the  provisioning  list  is  usually 
used  as  the  ISN.  The  PCC  for  nonprovisioning  items  may  be 
assigned  based  on  a  single  PCC  for  a  single  activity  on  a  single 
PCC  for  each  person  generating  nonprovisioning  SSR  transactions 
or  some  other  criteria.  The  ISN  is  generally  assigned  beginning 
with  000001  each  day  and  progressing  sequentially.  The  000001 
ISN  may  appear  only  once  on  each  day  or  may  appear  only  once  per 
SSR  generating  individual  each  day  depending  on  the  SICC.  The 
methods  used  for  assigning  the  PCC  and  ISN  for  nonprovisioning 
items  is  causing  different  item  identifiers  to  be  assigned  iden¬ 
tical  control  data  elements  as  described  in  Volume  III. 
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2.  SICC  SSR  Processing  Phase.  The  actions  performed  in 
this  processing  phase  for  nonprovisioning  items  are  similar  to 
those  performed  for  provisioning  items.  The  major  difference 
lies  in  the  assignment  of  some  SSR  control  data  elements  for  non- 
provisioning  items  in  this  phase.  Also  while  automated  systems 
exist  to  generate  SSR  transactions  for  provisioning  items,  non¬ 
provisioning  SSR  transactions  are  manually  generated.  The  pro¬ 
cessing  within  the  automated  SSR  system  design  of  each  of  the 
Services  is  the  same  for  provisioning  and  nonprovisioning  SSR 
transactions;  however,  it  was  found  during  the  operational 
implementation  review  that  some  activities  were  not  using  the 
automated  SSR  system  to  process  nonprovisioning  SSR  transac¬ 
tions.  The  same  types  of  manual  actions  and  files  are  performed/ 
maintained  for  both  provisioning  and  nonprovisioning  SSR  trans¬ 
actions  in  this  processing  phase. 

3.  IMM  SSR  Processing  Phase.  A  distinction  is  made  between 
provisioning  and  non p ro v i s ioni ng  SSR  transactions  in  the  level 
of  support  provided  and  the  funding/budgeting  area.  All  other 
manual  and  automated  actions  are  identical.  The  level  of  sup¬ 
port  determination  for  nonprovisioning  SSR  transactions  differs 
from  this  determination  for  provisioning  SSR  transactions  in  the 
Army  and  GSA.  The  Army  routinely  assigns  nonprovisioning  SSR 
items  a  level  of  support  equating  to  AAC  'J'  (Centrally  Procure, 
Nonstock).  GSA  normally  assigns  a  level  of  support  equating  to 
AAC  'J'  or  AAC  'L*  (Local  Procurement).  A  distinction  is  made 
by  DLA  in  that  nonprovisioning  items  supported  are  assigned  a 
funding  code  different  from  that  assigned  to  provisioning  items. 

4.  SICC  SSR  Advice  Processing  Phase.  There  are  two  varia¬ 
tions  in  this  processing  phase.  When  an  offer  advice  is  received, 
at  least  one  activity  was  forwarding  the  offer  to  the  item  orig¬ 
inator  (field  activity)  for  the  offer  accept /re jec t  decision. 
Advice  and  NSN  notifications  for  nonprovisioning  items  are  for¬ 
warded  to  the  item  originator. 

5 .  Summary 


The  primary  differences  between  provisioning  item  and 
nonprovisioning  item  processing  include: 

SSR  generation  criteria. 

-  Assignment  of  SSR  control  data  elements. 

Method  of  Sup po r t / le ve 1  of  support  determination  by 
IMMs  . 

Automated  processing  in  SICC  automated  SSR  applica¬ 
tions. 

The  determination  of  the  SSR  generation  criteria  to  be 
used  is  outside  the  scope  of  the  study;  however,  it  would  seem 
that  the  same  criteria  should  be  used  for  provisioning  and  non¬ 
provisioning  items.  The  assignment  of  SSR  control  data  elements 
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is  causing  duplicate  or  apparent  duplicate  SSR  submissions  to  be 
made.  SSR  control  data  elements  should  be  assigned  in  a  format 
and  content  to  preclude  generation  of  these  duplicate  transac¬ 
tions.  Nonprovisioning  SSR  transactions  should  be  input  to  SICCs 
automated  SSR  applications  for  validation  and  posting  to  the  SSR 
suspense  file  in  the  same  manner  as  provisioning  SSR  transactions. 
The  IMMs  should  not  be  using  the  provislonlng/nonprovlsionlng 
distinction  in  making  method/level  of  support  determinations. 

Since  these  differences  appear  to  be  either  invalid  in  concept 
or  an  apparent  abuse  of  the  system  as  a  whole,  the  distinction 
between  SSR  transactions  for  provisioning  items  and  nonprovision¬ 
ing  items  should  be  eliminated  and  these  items  should  be  pro¬ 
cessed  identically  by  both  SICCs  and  IMMs. 

H .  SSR  CHANGE  TRANSACTIONS 

1 .  General 


The  IMM  Manual  provides  for  preparation  and  submission 
of  changes  to  SSR  transactions  when  a  review  of  design  changes 
indicates  a  change  in  the  quantities  of  items  for  which  supply 
support  has  been  previously  requested.  A  time  limit  of  two 
years  from  the  DOR  of  the  initial  submission  is  established  by 
the  IMM  Manual  for  the  submission  of  changes.  Subsequent  to  two 
years,  increases  in  quantities  should  be  submitted  as  new  require¬ 
ments  for  established  items. 

The  IMM  Manual  provides  a  Type  Change  Code  (TCC)  to 
distinguish  initial  submittal  provisioning  SSR  transactions, 
nonprovisioning  SSR  transactions  and  SSR  change  transactions 
from  one  another.  The  relationship  between  the  TCC  and  type  of 
SSR  transaction  is  shown  in  Table  V-7 .  As  shown  by  this  table, 
separate  TCCs  exist  for  use  in  PDSSR  transactions  and  LISSR 
transactions  except  for  nonprovisioning  SSR  transactions. 

The  instructions  for  completing  PDSSR  transactions  indi¬ 
cate  that  a  PDSSR  transaction  with  TCC  ■  'P*  shall  be  submitted 
when  end  Item  program  changes  occur  or  design  changes  affecting 
quantity  fields  on  initial  submission  LISSR  transactions  occur. 

If  the  end  Item  program  data  in  the  PDSSR  transaction  is  the 
only  change,  the  instructions  infer  that  only  the  PDSSR  transac¬ 
tion  need  be  submitted.  These  instructions  indicate  that  changes 
are  to  be  submitted  only  for  PDSSR  and  LISSR  transactions  which 
were  originally  submitted  under  TCC  -  'N.'  This  indicates  that 
changes  are  not  to  be  submitted  for  nonprovisioning  SSR  trans¬ 
actions.  Instructions  for  completing  the  TCC  for  LISSR  transac¬ 
tions  calls  for  entering  a  TCC  ■  'V'  for  nonprovisioning  SSR 
transactions  and  entering  an  appropriate  TCC  in  provisioning 
LISSR  transactions  only  when  the  associated  PDSSR  contains  a  TCC 

»  'P.  « 
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TCC/SSR  TRANSACTION  RELATIONSHIPS 


TCC 

TYPE  SSR  TRANSACTION 

N 

Initial  Submittal  PDSSR  Transaction 

V 

Nonprovisioning  PDSSR  or  LISSR  Transaction 

P 

PDSSR  Change  Transaction 

B  lank 

Initial  Submittal  LISSR  Transaction 

C 

Change  in  LISSR  Transaction  Quantities  to  Increase 

Retail  or  Replenishment  Quantity 

D 

Change  in  LISSR  Transaction  Quantities  to  Decrease/ 
Delete  Retail  or  Replenishment  Quantity 

R 

Superseded  Part.  Reduce  LISSR  Transaction  Retail  and 
Replenishment  Quantities  by  the  Amount  Reflected. 

S 

Superseded  Part.  Provide  LISSR  Transaction  Retail  and 
Replenishment  Quantities  Reflected. 

T 

Correction  of  Technical  or  Clerical  Errors  other  than 
Retail  and  Replenishment  Quantities  to  LISSR  Trans¬ 
action  for  Which  Accept  Advice  has  been  Received. 

Table  V-7 

The  IMM  is  required  to  provide  advice  transactions  only 
for  SSR  Change  transactions  containing  TCC  equal  to  'S.* 

2.  Processing  Considerations.  The  generation  and  processing 
of  SSR  change  transactions  from  both  a  SICC  and  IMM  basis  varies 
widely  among  the  Components.  This  variation  carries  through  in 
both  the  Systems  Design  and  Operational  processes  reviewed. 

a .  Systems  Design 

The  variations  in  systems  design  lie  primarily  in 
the  areas  of  automated  generation  of  SSR  change  transactions, 
package  validations,  match  validations,  and  SSR  Suspense  File 
posting.  Of  the  Service  SICCs,  only  the  Army  includes  automated 
generation  of  some  SSR  change  transactions.  The  Army  systems 
design  provides  for  automatic  generation  of  SSR  change  transac¬ 
tions  affecting  the  retail  and  replenishment  quantities  of  pre¬ 
viously  submitted  provisioning  SSR  transactions.  When  changes 
to  these  quantities  occur  an  SSR  candidate  is  passed  to  the  SSR 
converter  program  module  of  the  CCSS  SSR  Application  (see  Volume 
II,  Part  1).  This  SSR  candidate  is  converted  into  a  PDSSR  trans¬ 
action  with  TCC  »  'P*  and  a  LISSR  transaction  with  TCC  -  'C'  when 
quantities  are  increased,  or  TCC  “  'D'  when  quantities  are  de¬ 
creased.  All  other  SSR  change  transactions  in  the  Army  and  all 
SSR  change  transactions  in  the  other  Services  are  generated  on  a 
manual  basis.  These  manually  generated  SSR  change  transactions 
may  then  be  input  to  the  SICC  automated  SSR  Application. 
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Package  validations  are  generally  the  same  from 
Component  to  Component  and  consist  of  a  check  for  a  PDSSR  with 
TCC  -  'P'  accompanied  by  one  or  more  LISSR  transaction  with  TCC 

-  'C,'  'D,'  'R,'  'S,'  or  'T'  and  vice  versa.  Also  LISSR  trans¬ 

actions  with  TCC  =  'R'  are  checked  to  ensure  they  are  accompanied 
by  a  LISSR  transaction  with  TCC  =  'S.'  Only  one  Component  makes 

a  check  on  both  a  SICC  and  IMM  basis  for  a  PDSSR  with  TCC  =  'P' 
and  not  accompanied  by  associated  LISSR  transactions.  Although 
this  condition  appears  to  be  valid  as  mentioned  above,  the  other 
SICCs  and  IMMs  will  reject  this  PDSSR  transaction  as  a  package 
error  . 


Match  validation  of  SSR  change  transactions  generally 
consists  of  matching  these  transactions  on  control  data  elements 
to  initial  submission  SSR  transactions  on  the  SSR  Suspense  File. 
As  discussed  in  Volume  III,  generally  the  Services  as  SICCs  and 
IMMs  perform  this  match  validation  while  DLA  as  a  CIMM  does  not. 
Whether  or  not  this  validation  is  performed  and  the  results  of 
this  validation  has  a  direct  bearing  on  the  posting  of  SSR  change 
transactions  to  the  SSR  Suspense  File. 

The  posting  of  SSR  transactions  to  Component  SSR 
Suspense  Files  was  presented  from  a  system  design  standpoint  in 
Volume  II  and  from  a  validation  standpoint  in  Volume  III.  A 
review  of  these  discussions  shows  the  wide  variance  of  transac¬ 
tion  posting  practices  among  the  Components.  The  Army  generally 
posts  all  valid  transactions  and  most  invalid  transactions  in¬ 
cluding  SSR  change  transactions  to  its  SSR  Suspense  File.  The 
Navy  maintains  separate  SSR  Suspense  Files  for  outgoing  and 
incoming  SSR  transactions.  Only  valid  SSR  change  transactions 
(no  data  elements  in  error,  proper  package  format,  and  match  to 
initial  submission  on  file)  are  posted  to  the  SICC  SSR  Suspense 
File.  All  Incoming  SSR  change  transactions  are  posted  to  the 
WIMM  SSR  Suspense  File.  In  the  Air  Force,  only  valid  SSR  change 
transactions  are  posted  to  the  SSR  Suspense  File.  The  Air  Force 
performs  the  match  validation  for  SSR  change  transactions  and 
the  match  must  be  an  initial  submission  provisioning  LISSR  trans¬ 
action  or  a  nonprovisioning  LISSR  transaction.  DLA  does  not 
perform  the  match  validation  and  posts  only  LISSR  change  tran¬ 
sactions  with  TCC  »  'S'  to  its  SSR  Suspense  File.  These  LISSR 
change  transactions  are  processed  as  an  initial  submission  by 
DLA. 


Within  each  Service  SSR  Application,  SSR  change  trans¬ 
actions  are  posted  to  the  SSR  Suspense  File  and  validated  to  main¬ 
tain  an  audit  trail  of  the  item  required  on  an  SICC  basis.  From 
an  IMM  viewpoint,  when  these  transactions  are  validated  and  posted 
to  the  SSR  Suspense  File,  it  is  done  also  to  maintain  an  audit 
trail  except  for  those  with  TCC  *  'S.'  SSR  change  transactions 

with  TCC  other  than  'S'  are  generally  listed  for  manual  processing 
by  an  item  manager.  The  automated  processing  for  SSR  change 
transactions  containing  TCC  «  'S'  was  described  in  Volume  II. 
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b .  Operational  Implementation 

During  the  operational  implementation  review,  only 
one  activity  was  found  to  have  a  specific  procedure  for  generat¬ 
ing  and  processing  SSR  change  transactions  on  a  manual  basis. 
These  SSR  change  transactions  are  generated  from  Design  Change 
Notices  (DCNs)  for  Provisioning  SSR  transactions  previously  sub¬ 
mitted.  All  other  SICCs  reviewed  had  no  established  procedures 
for  generating  SSR  change  transactions;  however,  all  SICCs  indi¬ 
cated  that  SSR  changes  requiring  a  TCC  -  'T*  are  not  generated. 
One  activity  reviewed  indicated  that  TCCs  C,  D,  R,  S  &  T  were 
not  used  and  SSR  change  transactions  were  submitted  as  initial 
submittals . 

The  only  SSR  change  transactions  which  were  found  to 
be  regularly  processed  by  IMMs  are  those  containing  a  TCC  *»  *S.* 
These  are  processed  as  initial  submittal  SSR  transactions.  The 
remainder  of  the  SSR  change  transactions  received  are  generally 
listed  for  manual  functional  processing  generally  by  an  item 
manager.  Whether  or  not  item  managers  actually  review  these 
items  or  take  any  specific  actions  based  on  receipt  of  these 
transactions  is  unknown. 

3.  SSR  Change  Transaction  Volumes.  The  volumes  of  SSR 
change  transactions  were  presentd  in  Volume  III.  These  volumes 
are  summarized  in  Figure  V-8  below. 

SSR  CHANGE  TRANSACTION  VOLUMES 


Category 

X  of  Category 

PDSSR  SICC  to  CIMM 

1.0 

SICC  to  WIMM 

0.2 

LISSR  SICC  to  CIMM 

0.4 

SICC  to  WIMM 

0. 1 

Source:  DODSSR  Data  Collection. 


Figure  V-8 

The  extremely  low  volumes  indicate  that  either  DCNs  requiring 
SSR  change  transactions  are  not  occurring,  or  the  IMM  Manual  is 
unclear  as  to  when  SSR  change  transactions  are  required  or  should 
be  generated,  or  SICCs  are  submitting  SSR  change  transactions 
without  the  appropriate  TCC  entered. 

A .  Summary 

The  IMM  Manual  provides  criteria  for  when  SSR  change 
transactions  are  required,  procedures  for  generating  these  SSR 
change  transactions  and  conditions  under  which  advice  is  required 


124 


from  an  IMM.  The  low  volume  of  SSR  change  transactions  in  con¬ 
junction  with  the  variety  of  generating  and  processing  methods 
on  both  an  automated  and  manual  basis  indicate  that  the  IMM 
Manual  is  not  specific  enough  and,  in  fact,  leaves  much  to  indi¬ 
vidual  Interpretation. 

The  fact  that  some  activities  submit  SSR  change  transac¬ 
tions  for  nonprovisioning  SSRs  and  others  do  not,  and  that  some 
automated  validations  allow  changes  to  nonprovisioning  SSRs 
while  others  do  not,  shows  clarification  is  required  in  this  area 
The  posting  or  nonposting  of  SSR  change  transactions  to  SSR 
Suspense  Files  in  terms  of  an  audit  trail  must  be  further  defined 
In  addition,  allowing  changes  to  be  submitted  for  two  years  after 
the  DOR  and  providing  for  a  120-day  audit  trail  prior  to  file 
purge  seems  to  be  contradictory  and  should  be  clarified.  The 
relative  usefulness  of  providing  changes  to  program  data  and  the 
use  of  TCC  -  'T'  indicates  that  these  types  of  changes  are  good 
candidates  for  elimination.  The  relationships  between  the  TCCs 
provided  in  the  IMM  Manual  and  the  change  codes  specified  in 
MIL-STD-1552  to  be  used  as  part  of  the  PLISN  need  to  be  reviewed 
to  determine  the  necessity  for  two  sets  of  change  codes  to  con¬ 
vey  the  same  basic  information.  Also,  the  necessity  of  SSR 
change  transactions  must  be  considered  in  relation  to  IMM  actions 
based  on  these  changes. 

The  provision  for  providing  advice  to  SICCs  only  for  SSR 
change  transactions  containing  TCC  “  'S'  does  not  appear  to  be 
sufficient.  SICCs  should  be  provided  advice  on  all  SSR  change 
transactions  submitted  so  that  corrective  action  may  be  taken 
when  SSR  change  transactions  are  not  matched  to  the  automated 
SSR  Suspense  File  or  when  the  SSRs  contain  invalid  data.  SICCs 
should  also  be  provided  accept  advice  by  IMMs  when  SSR  change 
transactions  are  valid.  This  is  especially  important  where 
retail/replenishment  quantity  increases  are  concerned. 

I .  JOINT  PROVISIONING 

1 .  Background 


The  IMM  Manual  provides  for  communication  of  SSR  item 
data  for  claimant  Service  users  by  the  Lead  Services  when  two 
or  more  Services  are  jointly  provisioning  an  end  item.  Claimant 
Services  users  are  communicated  using  an  Additional  User  Trans¬ 
action  under  the  SSR  procedures.  The  additional  user  transac¬ 
tion  basically  consists  of  LISSR  control  data  elements  and  the 
claimant  Service  provisioning  activity  code.  Under  this  proce¬ 
dure,  the  Lead  Service  would  add  claimant  Service  requirements 
to  its  own  requirements  before  submitting  SSR  transactions  to 
CIMMs. 
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Under  joint  provisioning,  maintenance  significant  items 
are  identified  at  a  joint  SM&R  coding  conference.  This  joint 
conference  is  attended  by  the  end  item  contractor  and  represen¬ 
tatives  of  each  Service  involved  in  the  joint  provisioning  effort. 
Each  Service  determines  its  own  requirements  for  each  maintenance 
significant  item  subsequent  to  the  conference.  Each  Service 
submits  a  list  of  items  and  respective  quantities  to  be  procured 
on  the  end  item  contract  to  the  Lead  Service  generally  accom¬ 
panied  by  a  MIPR.  The  Lead  Service  then  submits  these  require¬ 
ments  along  with  its  own  to  the  contractor.  The  same  kind  of 
process  is  currently  available  for  consumable  items  managed  or 
IMC  coded  for  management  by  a  CIMM.  The  claimant  Service  deter¬ 
mines  its  requirements  for  each  CIMM  item  and  forwards  them  to 
the  Lead  Service.  The  Lead  Service  then  includes  the  other 
Service  requirements  with  its  own  in  the  LISSR  transactions  for 
these  items  and  also  generates  the  appropriate  Addi-tional  User 
transactions. 

2 .  Current  Processing  Considerations 

A  review  of  current  generation  and  processing  of  SSR 
transactions  under  joint  provisioning  reveals  that  only  the 
Electronics  Provisioning  Subsystem  in  the  Navy  is  capable  of 
automatically  generating  Additional  User  transactions  and  that 
only  the  Air  Force  SSR  Application  is  able  to  include  subor¬ 
dinate  Service  requirements  in  the  automated  requirements  com¬ 
putation  process. 

The  SSR  transactions  generated  on  an  automated  basis 
from  the  Provisioning  Subsystems  of  the  Services  do  not  include 
requirements  for  other  Services.  These  requirements  must  be 
manually  added  to  Lead  Service  requirements  and  keypunched  in 
new  SSR  transactions  prior  to  submittal  to  CIMMs.  Additional 
User  transactions  for  these  items  must  also  be  manually  coded 
and  keypunched.  SSR  transactions  for  items  required  by  a  another 
Service,  but  not  required  by  the  Lead  Service  must  also  be  man¬ 
ually  coded  and  keypunched.  If  these  transactions  are  to  be 
validated  and  posted  to  SSR  Suspense  Files,  they  must  then  be 
input  as  manually  generated  SSR  transactions  to  the  Lead  Service 
SSR  Application.  Because  of  the  additional  manual  processing 
required  and  the  resulting  potential  for  introduction  of  valida¬ 
tion  errors,  generally  each  of  the  Services  included  under  the 
joint  provisioning  contract  generates  and  submits  its  own  SSR 
transactions  . 

The  results  from  the  DODSSR  'Data  Collection  are  con¬ 
sistent  with  this  single  Service  SSR  submittal  under  joint  pro¬ 
visioning  contract  concept.  The  finding  that  only  0.2  percent 
of  the  LISSR  transactions  within  the  DODSSR  data  base  were 
accompanied  by  an  Additional  User  Transaction  validates  that 
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the  single  Service  submitter  concept  is  being  used.  In  addi¬ 
tion,  a  review  of  the  commonality  listing  revealed  the  same 
items  appearing  on  multiple  LISSR  transactions  from  activities 
of  different  Services  containing  relatively  consistent  control 
data  elements.  These  transactions  were  submitted  with  different 
DORs ,  but  the  differences  in  DOR  were  small  enough  to  be  attrib¬ 
utable  to  Service/  Activity  processing  differences. 

3 .  Analysis  of  SSR  Processing  Under  Joint  Provisioning 

The  generation  and  submittal  of  SSR  transactions  by  each 
Service  under  a  joint  provisioning  contract  suggests  that  the 
current  SSR  procedures  are  not  being  used  when  applied  to  joint 
provisioning.  Since  the  Services  have  not  designed  their  auto¬ 
mated  systems  to  process  joint  provisioning  contracts  a  signifi¬ 
cant  amount  of  manual  processing  is  required  subsequent  to 
generation  of  SSR  transactions  by  the  Lead  Service.  This  manual 
processing  not  only  adds  to  the  validation  error  rate,  but  may 
significantly  increase  processing  time  at  the  Lead  Service  pro¬ 
visioning  activity  prior  to  submittal  of  the  SSR  transactions. 

In  addition,  the  current  SSR  procedures  in  the  IMM  Manual  do  not 
provide  for  forwarding  SSR  advice  or  NSN  notifications  to  claimant 
Services  by  either  the  CIMM  or  the  Lead  Service.  These  factors 
point  to  the  obvious  advantages  to  be  gained  by  each  service 
submitting  its  own  SSR  transactions. 

However,  there  is  a  distinct  disadvantage  to  the  SICCs 
in  conducting  SSR  generation  and  processing  in  this  manner. 

Under  the  current  system  ea  h  USSR  transaction  stands  on  its 
own  merit  in  the  method  and  le’el  of  support  determinations  made 
by  CIMMs.  This  practice  has  been  repeatedly  criticized  by  the 
Services  as  causing  too  many  items  to  be  supported  as  centrally 
procured  nonstocked  instead  of  centrally  procured-centrally 
stocked.  If  SSR  requirements  for  all  Services  involved  under 
joint  provisioning  were  submitted  as  a  single  requirement  by  the 
Lead  Service,  it  is  reasonable  to  expect  some  of  the  items  that 
would  be  supported  as  centrally  procured-nonstocked  to  move  to 
the  stocked  category. 

From  this  discussion  it  is  apparent  that  the  IMM  Manual 
should  be  revised  to  provide  for  one  of  the  following  two  pro¬ 
cessing  concepts: 

(1)  The  Service  should  provide  an  automated  method 
of  adding  subordinate  Service  Requirements  to  Lead  Service 
requirements  in  their  automated  SSR  Applications;  the  Additional 
User  transaction  in  the  current  IMM  Manual  should  be  eliminated 
and  the  claimant  Service  provisioning  activity  should  be  provided 
in  the  LISSR  transaction;  and  the  IMM  Manual  should  provide  a 
means  of  providing  SSR  advice/NSN  notification  to  the  claimant 
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Service  provisioning  activity.  This  alternative  requires  the 
claimant  Service  to  maintain  a  record  of  SSR  items  required  on 
its  SSR  Suspense  File  for  matching  up  of  SSR  advice/NSN  notifi¬ 
cation  and  suppor t /nonsuppor t  notification  to  provisioning  ele¬ 
ments  . 


(2)  The  IMM  Manual  should  be  revised  to  provide 
that  all  SSR  transactions  should  be  generated  and  submitted  on  a 
single  Service  basis  and  the  Additional  User  Transactions  should 
be  eliminated.  This  alternative  requires  that  a  provision  be 
added  to  the  IMM  Manual  to  sum  the  SSR  requirements  for  the  same 
item  submitted  in  separate  LISSR  transactions  prior  to  the  Method/ 
Level  of  Support  determination.  This  summary  of  requirements 
would  pertain  only  when  multiple  SSR  transactions  were  received 
by  a  CIMM  for  the  same  item  from  different  SICCs  in  the  same  pro¬ 
cessing  cycle  . 

J .  NIMSR  PROCESSING 

1 .  Processing  Considerations 

The  generation  and  processing  of  NIMSR  transactions  is 
currently  done  under  the  auspices  of  the  joint  regulation  cover¬ 
ing  the  elimination  of  duplication  in  the  management  and  logistics 
support  of  multi-used  nonconsumable  items  (Appendix  D,  Reference 
21).  Under  the  procedures  contained  in  this  joint  regulation, 
the  NIMSR  process  is  limited  to  a  manual  process  by  virtue  of 
the  NIMSR  form  specified.  A  facsimile  of  the  NIMSR  form  as  con¬ 
tained  in  the  joint  regulation  is  shown  in  Figure  V-9.  The  man¬ 
ual  processing  performed  by  each  Service  was  described  in  Volume 
II.  This  processing  is  summarized  below. 

Outgoing  NIMSR  processing  in  each  of  the  Services  gener¬ 
ally  begins  about  the  same  time  the  SICC  SSR  Processing  Phase 
begins  for  consumable  items.  The  NIMSR  forms  are  initiated  by 
cataloging  elements  in  all  Services  except  the  Air  Force.  The 
catalogers  generally  complete  blocks  1,  3,  4,  5,  and  10  of  each 

NIMSR  form.  These  forms  are  then  forwarded  to  item  management 
or  provisioning  elements  for  completion  of  the  submitter  portion 
of  each  form.  The  completed  forms  are  returned  to  cataloging 
elements  for  submission  to  the  PICA.  These  cataloging  elements 
are  responsible  for  maintaining  a  manual  suspense  file  and 
following  up  on  uncompleted  NIMSR  forms.  This  cataloging  ele¬ 
ment  is  the  same  element  responsible  for  submitting,  maintaining 
suspense  files  and  following  up  on  SSR  transactions.  The  Air 
Force  is  an  exception  to  this  general  sequence  of  events.  As 
explained  in  Volume  II,  NIMSRs  are  generated  and  processed 
totally  by  item  management  elements  in  the  Air  Force. 

This  difference  in  processing  on  an  organizational  basis 
has  a  definite  effect  on  timeliness  of  processing.  The  cata¬ 
loging  element  in  the  Army,  Navy,  and  Marine  Corps  enters  the 


SAMPLE  NIMSR 


NONCONSUMABLE  ITEM 

MATERIEL  SUPPORT  REQUEST 

1.  SUHUTIER 

2.  PREPARING  OFFICE 

3.  PICA 

4.  DATE  OF  REQUEST 

5a.  NSN 

5b.  AF/EMAC 

5c.  NAVY  OOG  03DE 

6.  INITIAL  QUANTITY 

7.  IAIE  REQUIRED 

8.  LEVEL  OF  SUPPORT 

9.  MANAGEMENT  LEVEL  (DDE 

10.  M)E  RULE 

11.  SHIP  TO 

12.  APPLICATION 

13.  SYSTEMS  SUPPORTED 

14.  INSTALLED  QUANTITY 

15.  TYPE  reOGRAM 

16.  OPERATIONAL  USAGE 

17.  12  MONTH  DEMANDS 

18.  UNSERVICEABLE  RETURNS 

19.  PICA  RESPONDING  OFFICE 

20.  LEVEL  OF  SUPPORT 

21.  METHOD  OF  SUPPORT 

22.  DATE  PUNDS  REQUIRED 

23.  ASSET  AVAILABILITY  DATE 

24.  UNIT  COST 

25.  TOTAL  DOLLAR  VALUE 

26.  PROCUREMENT  LEAD  TIME 

27.  REPLENISHMENT  Rtfff  DUE  IME(S) 

28.  UNSERVICABLE  RECEIVING  ACTIVITY 

29.  REMARKS 

Figure  7-9 
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Date  of  Request  (block  4)  as  the  process  date  when  the  NIMSR  Is 
initiated  which  is  prior  to  completion  by  item  management  or  pro¬ 
visioning  elements.  Since  a  single  functional  element  in  the 
Air  Force  initiates,  completes  and  mails  each  NIMSR  more  timely 
processing  would  be  expected  to  occur.  The  result  of  the  Data 
Collection  discussed  in  Volume  III  show  this  to  be  true  with 
SICA  Internal  Wait  Times  of  10  days  to  two  weeks  larger  on  the 
average  in  the  Army  and  Navy  than  in  the  Air  Force. 

Suspenses  on  outgoing  NIMSRs  are  generally  begun  on  the 
date  mailed,  not  the  DOR,  and  the  initial  suspense  prior  to  fol¬ 
lowup  is  usually  30  days.  The  SICA  may  then  followup  either  by 
telephone  or  letter,  although  no  specific  standard  or  followup 
procedures  are  provided  by  the  joint  regulation  covering  NIMSR 
usage.  The  data  collection  revealed  average  transmission  times 
of  10  days  to  three  weeks  and  PICA  processing  times  averaging 
over  36  days.  These  times  make  the  30  day  standard  used  on  an 
activity  basis  seem  rather  unrealistic. 

Incoming  NIMSR  processing  is  predominantly  an  item  man¬ 
agement  function  and  in  the  Air  Force  and  Marine  Corps  incoming 
NIMSRs  are  directed  to  item  management  elements.  The  Army  and 
Navy  cataloging  elements  perform  screening  for  PICA  validation 
prior  to  forwarding  NIMSR  to  item  management  elements.  Incoming 
NIMSRs  are  completed  by  item  management  elements  totally  and 
returned  to  the  SICA  via  mail.  The  timing  of  NIMSR  related  cata¬ 
loging  actions  varies  from  Service  to  Service  in  terms  of  whether 
these  actions  are  completed  before  or  after  the  completed  NIMSR 
is  returned  to  the  SICA.  In  the  Air  Force  the  item  management 
element  completes  cataloging  actions  for  NIMSRs,  while  catalog¬ 
ing  elements  perform  these  actions  in  the  other  Services.  No 
locally  established  timeframes  for  processing  incoming  NIMSRs 
were  found  to  exist. 

2 .  Feasibility  of  Automating  NIMSR  Processing 

The  current  manner  of  processing  NIMSRs  is  similar  to 
the  method  of  processing  Non p ro vis  ion  in g  SSRs  prior  to  implemen¬ 
tation  of  the  IMM  Manual.  At  that  time  nonprovisioning  SSRs 
were  identified  using  a  form  similar  to  the  NIMSR  form  in  use 
today.  Nonprovisioning  SSR  generation  and  processing  was  a 
totally  manual  process  at  that  time;  however,  the  implementation 
of  the  IMM  Manual  combined  procedures  for  provisioning  and  non¬ 
provisioning  SSRs,  and  as  a  result,  nonprovisioning  SSRs  may 
now  be  processed  mechanically.  The  potential  for  automating 
NIMSR  generation  and  processing  depends  on  identification  of 
items  as  NIMSR  candidates  during  the  Provisioning  Processing 
Phase  or  SICC  SSR  Processsing  Phase,  and  providing  automated 
formats  to  accommodate  each  data  element  on  the  NIMSR  form. 
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One  Service,  the  Army,  examines  SSR  candidates  in  its 
SSR  Application  for  the  presence  of  a  non-blank  NIMSC.  This 
test  weeds  out  SSR  candidates  that  are  nonconsumable  items  and 
require  NIMSR  preparation  and  submittal.  If  an  automated  format 
existed,  it  appears  that  NIMSRs  could  be  automatically  generated 
as  a  direct  follow-on  to  this  identification  similar  to  the  way 
SSRs  are  generated  by  that  Application. 

It  is  significant  to  note  that  the  major  control  data 
elements  and  key  data  elements  used  in  SSR  processing  are  also 
required  in  NIMSR  processing.  These  data  elements  include  Activ¬ 
ity  Code  To  (PICA),  Activity  Code  From  (Submitter),  Date  of 
Request,  NSN,  Retail  Quantity  (Initial  Quantity),  and  Replenish¬ 
ment  Quantity  (12-Month  Demand).  In  addition,  other  data  ele¬ 
ments  used  in  SSR  processing  are  present  on  each  NIMSR  form; 
e.g.,  Date  Repair  Parts  Required  (Date  Required)  and  Support 
Date  (Asset  Availability  Date).  This  illustrates  that  it  would 
be  possible  to  automate  NIMSR  processing  under  the  SSR  Proce¬ 
dures  using  the  same  general  controls  and  adjusting  the  request 
and  advice  formats  to  accommodate  data  elements  required  for 
NIMSR  processing.  The  automation  of  NIMSR  generation  would 
greatly  reduce  the  internal  processing  time  at  the  SICA  and 
would  allow  NIMSRs  to  be  sent,  received  and  replied  to  using 
AUTODIN  which  would,  in  effect,  eliminate  virtually  all  of  the 
current  transmission  times. 

Although  the  potential  for  automating  NIMSRs  under  the 
SSR  Procedures  exists  and  the  potential  reduction  in  processing 
times  makes  this  mechanization  desirable,  the  volume  of  transac¬ 
tions  must  also  be  considered.  The  data  collection  resulted  in 
about  3,000  NIMSRs  over  an  8-month  period.  This  is  compared  to 
over  38,000  nonprovisioning  SSRs  collected  during  the  same  8-month 
period.  The  number  of  NIMSRs  currently  being  processed  does  not 
appear  to  warrant  the  expense  of  developing  automated  processes 
and  formats.  However,  when  the  volume  of  NIMSRs  being  processed 
between  activities  reaches  a  significant  level,  it  appears  to  be 
feasible  to  automate  NIMSR  processing  under  the  SSR  Procedures. 

K.  SUMMARY  ANALYSIS  AND  CONCLUSIONS 

1.  General .  The  previous  sections  of  this  Chapter  have 
compared  on  a  total  systems  basis  the  sequence  and  actions  relat¬ 
ing  each  major  event  to  the  processing  phases  within  the  Concep¬ 
tual  Systems  Model.  These  sections  show  the  large  variations 
among  SICC/IMMs  in  the  sequence  of  processing  actions,  types  and 
numbers  of  files  maintained,  techniques  of  file  posting  and  up¬ 
dating,  establishment  of  internal  and  external  controls,  and 
types  of  inputs  accepted  and  outputs  produced.  This  section 
presents  the  study  team  findings  related  to  the  systems  approach 
which  are  required  to  meet  the  objectives  of  the  study  assign¬ 
ment.  These  findings  are  presented  as  they  relate  to  current 
systems  changes  and  as  they  relate  to  a  system  redesign  effort. 
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2.  System  Considerations.  The  study  team  found  three 
systems  characteristics  which  require  revision.  These  charac¬ 
teristics  include: 

*  Processing  Cycles 

*  Item  Processing  vs  Package  Processing 

"  Job  Stream  Considerations 

The  first  and  second  characteristics  apply  to  both  manual  and 
automated  processing  while  the  third  applies  only  to  automated 
processing . 

a.  Processing  Cycles.  The  processing  cycle  refers  to 
how  often  certain  actions  are  accomplished.  This  terminology 
is  commonly  used  in  automated  data  processing,  but  may  be 
applied  equally  as  well  to  manual  actions.  SSR  transactions 
whether  they  be  outgoing  or  incoming  are  processed  on  a  cyclic 
basis.  During  the  operational  Implementation  review  the  study 
team  found  that  on  a  manual  basis  this  processing  cycle  may  be 
from  10  days  to  two  weeks  for  incoming  LISSR  transactions,  but 
is  usually  dally  for  outgoing  SSR  transactions.  Automated  pro¬ 
cessing  cycles  vary  among  the  Components  and  even  among  activ¬ 
ities  within  the  same  Component.  Some  automated  systems  are 
designed  with  multiple  processing  cycles;  e.g.  the  Air  Force  SSR 
Application  contains  a  daily  cycle  and  a  monthly  cycle.  All 
Component  automated  SSR  Applications  were  designed  to  contain  a 
daily  processing  cycle  although  most  of  these  applications  also 
contain  other  processing  cycles.  The  system  design  activities 
of  the  Components  have  generally  recommended  that  the  dally  pro¬ 
cessing  cycle  be  executed  on  a  dully  basis;  however,  during  the 
opezatlonal  Implementation  review  it  was  noted  that  each  opera¬ 
tional  activity  is  allowed  to  determine  how  often  automated 
applications  are  scheduled.  The  activities  reviewed  generally 
scheduled  or  intended  to  schedule  the  automated  daily  SSR  pro¬ 
cessing  two  to  three  times  weekly.  These  varying  processing 
cycles  delay  processing  of  SSR  transactions  on  both  a  manual  and 
automated  basis.  This  delay  should  be  eliminated  by  processing 
all  types  of  SSR  transactions  including  locally  generated  in¬ 
quiries  on  a  dally  basis.  Since  most  of  the  processing  accom¬ 
plished  in  other  processing  cycles  is  related  to  purging  SSR 
History  Files  and  producing  functional  listings  or  operational 
reports,  these  processing  cycles  may  not  require  a  change. 


b.  Item  Processing  versus  Package  Processing.  The 
study  team  found  that  the  automated  systems  design  of  each 


Component  is  geared  to  processing  on  a  item  basis  and  only  pro¬ 
cesses  items  on  a  package  basis  when  purging  items  from  automated 
SSR  Suspense/History  Files  and  to  meet  the  IMM  Manual  require¬ 


ment  that  LISSR  transactions  be  submitted  in  packages  accom¬ 


panied  by  a  PDSSR  transaction.  Manual  processing  however,  is 
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geared  to  processing  items  in  groups  or  packages.  The  package 
processing  concept  tends  to  delay  processing  on  a  manual  and 
automated  basis  when  all  items  within  a  package  must  success¬ 
fully  complete  one  action  or  major  event  (e.g.,  validation) 
before  any  of  the  items  may  continue  to  the  subsequent  pro¬ 
cessing  action  or  major  event.  This  package  processing  concept 
should  be  eliminated  to  improve  the  processing  flow  for  each 
item.  The  elimination  of  this  concept  is  explored  further  below 
in  the  Input  section. 


c.  Job  Stream  Considerations.  Automated  processing 
cycles  may  consist  of  a  single  program  module  or  of  several 
program  modules.  It  is  a  common  practice  to  execute  all  program 
modules  within  a  processing  cycle  together  in  job  stream  to  pro¬ 
vide  control  over  the  sequence  of  processing  actions.  The  study 
team  found  that  most  systems  were  designed  and  executed  using 
this  job  stream  concept;  however,  at  least  one  Component  wa 
scheduling  and  executing  its  SSR  Application  on  a  program  mod^  le 
by  program  module  basis  even  when  these  program  modules  are 
designed  to  perform  subsequent  actions  on  the  same  transactions 
(e.g.,  outgoing  LISSR  transactions).  To  provide  proper  sequenc¬ 
ing  and  control  of  processing  actions  program  modules  within  the 
same  processing  cycle  should  be  chained  together  into  job  streams. 
There  also  seems  to  be  a  potential  for  integrating  or  chaining 
the  Provisioning,  Requirements  Computation  and  SSR  Applications 
together  into  single  job  streams  in  the  Army  and  Navy,  where 
these  other  actions  have  been  successfully  automated. 


Inputs 


The  most  basic  input  to  the  system  is  the  originating 
document  which  leads  to  the  generation  of  SSR  transactions. 

This  original ing  document  is  the  Provisioning  Technical  Docu- 
tation  submitted  by  the  end  item  contractor  for  provisioning  SSR 
items  and  is  most  often  item  recommendation  documentation  from 
field  activities  for  nonprovisioning  SSR  items.  These  origi¬ 
nating  documents  contain  the  basic  Information  necessary  to 
generate  SSR  transaction  i  regardless  of  whether  this  generation 
is  performed  on  a  manual  or  automated  basis. 


Within  the  systems  designed  to  generate  and  process 
Supply  Support  Requests,  the  SSR  transactions  and  related  tech¬ 
nical  data  become  the  inputs.  In  this  section,  PDSSR  transac¬ 
tions,  LISSR  transactions  and  catalog  transactions  will  be 
considered  as  inputs.  Other  types  of  SSR  transactions  are  con¬ 
sidered  as  output  or  controls  in  subsequent  sections.  Within 
the  current  systems,  these  inputs  cannot  be  easily  changed  or 
reformatted;  however,  under  the  system  redesign,  simplifications 
to  these  transactions  may  be  accomplished. 
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a.  PDSSR  Transactions.  This  transaction  serves  as  a 
header  card  for  each  group  of  items  submitted  to  an  IMM  for  sup¬ 
port.  This  transaction  serves  to  continue  the  package  processing 
concept  from  the  SICC  to  the  IMM.  It  is  this  package  processing 
concept  that  was  found  to  be  a  major  source  of  rejected  SSR  trans 
actions  in  the  data  analysis.  Volume  III,  and  t he  major  source  of 
errors  in  the  Validation  Analysis  Chapter  of  Volume  III.  The 
study  team  also  found  that  other  than  the  basic  control  data 
present  in  all  SSR  transactions,  only  the  Date  Repair  Parts  Re¬ 
quired,  Percent  End  Items  East  and  End  Item  Application  are  used 
regularly  by  IMMs .  The  other  data  elements  are  validated,  how¬ 
ever,  and  serve  only  to  cause  a  needless  rejection  of  SSR  items 
when  invalid.  The  system  redesign  should  eliminate  the  PDSSR 
transaction  totally  by  placing  the  useful  data  elements  in  their 
current  form  or  a  modified  form  (e.g.,  altering  the  End  Item 
Identification  to  a  Weapon  System/End  Item  Designator  Code)  in 
the  line  item  formats.  This  would  eliminate  the  problems  asso¬ 
ciated  with  processing  packages  of  SSR  transactions  while  retain¬ 
ing  the  useful  program  data. 

b.  LISSR  Transactions.  These  transactions  contain  basic 
item  data  required  to  process  an  item.  There  are  currently  both 
CIMM  and  WIMM  formats  for  active  NSN  items,  inactive  NSN  items, 
PSCN  items  and  Part  Number  items.  Each  of  these  format  types 
are  discussed  below  after  discussion  of  the  CIMM  versus  WIMM 
formats . 


(1)  CIMM  versus  WIMM  Formats.  There  are  four  data 
elements  required  in  WIMM  LISSR  transactions  which  are  not 
required  in  CIMM  LISSR  transactions.  These  four  data  elements 
are : 


*  MOE  Rule 

*  Materiel  Management  Aggregation  Code 

*  Item  Identification  Data  Receiver 

*  Item  Identifier  Data  Collaborator 

Of  these  data  elements  only  the  MOE  Rule  was  found  to  be  used  on 
an  interservice  basis.  The  Materiel  Management  Aggregation  Code 
is  an  Air  Force  unique  code  used  only  by  this  Service.  The  II 
Data  Receiver  and  II  Data  Collaborator  are  entered  only  by  the 
Army  and  Navy  and  are  for  intraservice  use.  The  MOE  Rule  is 
generally  validated  against  a  valid  MOE  Rule  Table  and  is  used 
as  a  basis  for  rejection  of  the  SSR  transaction  when  invalid  or 
for  generation  of  catalog  actions.  The  same  type  of  catalog 
actions  currently  are  performed  by  CIMM  by  extracting  the  re¬ 
quired  MOE  Rule  from  a  table  similar  to  that  used  by  WIMMs  for 
validation.  Since  these  four  data  elements  do  not  have  univer¬ 
sal  applicability  or  may  be  simply  determined  from  an  existing 
source  by  the  IMM,  these  data  elements  should  be  eliminated  from 


the  LISSR  transaction  formats  under  the  system  redesign  thereby 
eliminating  the  need  for  distinguishing  CIMM  transactions  from 
WIMM  transactions.  This  means  that  the  W-series  Document  Iden¬ 
tifier  Codes  may  also  be  eliminated. 

(2)  Active  NSN  Items 

Within  the  active  NSN  item  format  as  well  as 
the  other  item  formats  there  are  several  data  elements  used  for 
sequencing  and  control.  These  data  elements  include: 

*  Document  Identifier  Code  (DIC) 

*  Activity  Code  To  (ACT) 

*  Type  Change  Code  (TCC) 

*  Item  Serial  Number  (ISN) 

*  Date  of  Request  (DOR) 

*  Provisioning  Control  Code  (PCC) 

*  Activity  Code  From  (ACF) 

These  data  elements  are  located  in  noncontiguous  positions  in 
the  current  format  and  are  not  generally  in  the  sequence  used 
for  control  or  sorting  actions.  This  has  caused  several  Compo¬ 
nents  in  their  automated  SSR  Applications  to  establish  a  sort 
key  based  on  these  control  elements  and  attach  this  sort  key  to 
the  beginning  or  end  of  each  transaction.  This  situation  has 
caused  separate  program  modules  to  be  developed  to  establish  and 
append  this  sort  key  to  each  transaction.  The  study  team  found 
that  not  all  of  these  data  elements  were  used  for  control  by  all 
Components  and  that  they  are  used  in  varying  sequences.  The 
data  elements  to  be  used  as  controls  need  to  be  clearly  defined 
and  should  be  located  in  contiguous  positions  In  a  logical 
sequence  so  that  all  SICCs  and  IMMs  can  control  and  sequence 
transactions  the  same.  This  is  required  to  produce  consistent 
control  of  SSR  transactions  among  the  Components  and  to  elimi¬ 
nate  the  duplicate  reject  problems  encountered  when  SICCs  and 
IMMs  are  sequencing  and  controlling  processing  using  different 
data  elements  In  varying  order.  This  problem  was  documented  in 
the  Qualitative  Evaluation  in  Volume  III  and  was  also  discussed 
as  a  validation  problem.  There  is  another  duplicate  transaction 
problem  resulting  from  these  control  elements. 

This  second  problem  stems  from  the  assignment 
of  the  PCC  and  ISN  within  the  same  SICC.  Several  apparent 
duplicate  transactions  were  found  to  exist  within  the  DODSSR 
data  base.  These  are  apparent  duplicates  because  although  the 
transactions  contained  the  same  PCC,  ISN  and,  in  many  cases  DOR, 
and  were  from  the  same  activity  each  transaction  contained  a 
different  item  identifier.  This  situation  may  be  easily  rec¬ 
tified  for  both  provisioning  and  nonprovisioning  SSR  items. 

First,  a  PCC  should  be  assigned  to  a  single  provisioning  list  at 
the  SICC  activity.  This  PCC  should  not  be  assigned  to  more  than 
one  provisioning  list  and  should  not  be  reassigned  while  an  audit 


trail  exists  in  provisioning  or  SSR  files  for  items  assigned 
this  PCC.  In  addition,  the  PLISN  from  the  provisioning  list 
should  be  used  as  the  ISN.  This  PLISN  is  six  positions  in 
length  as  is  the  current  ISN  which  makes  the  fields  compatible. 
Also,  the  PLISN  as  defined  in  MIL-STD-1552  provides  for  the 
sixth  position  to  be  used  to  identify  changes  to  the  original 
item.  Using  this  PLISN  as  the  ISN  would  eliminate  the  need  for 
a  TCC  in  SSR  transactions  except  for  nonprovisioning  SSR  items. 
Using  this  PCC-PLISN  assignment  technique  requires  each  SICC  to 
establish  procedures  for  the  assignment  of  PCC  and  PLISN  to 
nonprovisioning  SSR  items  to  ensure  that  PCC-PLISN  (ISN)  com¬ 
binations  are  not  duplicated  within  the  same  SICC  activity.  In 
addition,  since  the  processing  distinctions  between  provisioning 
and  nonprovisioning  SSR  items  are  not  significant  as  pointed  out 
in  an  earlier  section,  nonprovisioning  SSR  transactions  require 
no  identifying  distinction,  thereby  eliminating  the  need  for  the 
current  TCC . 


For  active  NSN  items,  the  data  elements  used  for 
processing  and  making  the  advice  decision  include  the  NSN,  Retail 
Quantity,  Replenishment  Quantity,  and  Unit  of  Issue.  These  data 
elements  and  those  used  for  sequence/control  should  remain  in 
the  NSN  format . 

(3)  Inactive  NSN  items.  SSR  transactions  for  inac¬ 
tive  NSN  items  contain  the  same  control  elements  as  active  NSN 
items  and  the  same  discussion  applies.  In  addition,  the  same 
data  elements  are  generally  used  for  processing  both  active  and 
inactive  NSN  items.  Inactive  NSN  SSR  transactions  do  contain 
several  data  elements  not  required  for  active  NSN  items.  These 
data  elements  include: 

Source  Code 
Demilitarization  Code 
Procurement  Method  Code 
Shelf  Life  Code 
Production  Leadtime 
Uni t  Price 

These  data  elements  are  reported  to  be  used  for  reactivation  of 
the  NSN  and  generally  fall  into  the  Catalog  Management  Data 
Segment  of  DLSC  files.  An  item  becomes  inactive  when  it  is  no 
longer  used;  i.e.,  DLSC  files  have  no  recorded  users.  While  an 
item  is  in  an  inactive  status,  the  DLSC  file  records  are 
retained  including  the  Catalog  Management  Data.  DLA  includes 
automatic  generation  of  reactivation  transactions  when  a  DLSC 
inquiry  indicates  the  item  is  in  inactive  status.  The  addi¬ 
tional  data  elements  listed  above  are  usually  not  required  or 
used  to  reactivate  these  items.  This  indicates  that  a  distinc¬ 
tion  between  inactive  NSN  SSR  items  and  active  NSN  SSR  items  is 
not  required  and  therefore,  the  data  elements  listed  above 
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should  be  eliminated  from  NSN  SSR  item  formats  and  a  single  for¬ 
mat  for  all  NSN  SSR  items  should  be  used.  The  use  of  a  single 
format  for  NSN  SSR  items  will  eliminate  appearance  of  the 
Procurement  Method  Code  as  a  major  cause  of  validation  rejects 
as  discussed  in  the  validation  analysis.  These  validation 
rejects  were  caused  by  the  PMC  -  Unit  Price  matchup  performed  by 
DLA  in  an  attempt  to  distinguish  active  NSN  SSR  transactions 
from  inactive  NSN  SSR  transactions.  This  matchup  criteria  was 
found  to  be  causing  a  significant  amount  of  rejected  SSR  trans¬ 
actions  in  both  the  data  analysis  and  validation  analysis. 

(4)  PSCN  Items.  The  sam-e  basic  discussion  for 
inactive  NSN  items  holds  true  for  PSCN  items  also.  The  same 
basic  data  elements  are  used  for  control  and  processing.  The 
major  difference  between  processing  these  types  of  items  within 
DLA  lies  in  automated  reactivation  of  inactive  NSN  items  versus 
manual  activation  of  PSCN  items.  DLA  plans  to  automate  activa¬ 
tion  of  PSCN  items  also.  Based  upon  the  low  incidence  of  PSCN 
SSR  transactions  as  shown  by  the  DODSSR  data  collection  and  lack, 
of  reported  problems  with  processing  of  PSCN  items,  extensive 
revision  of  this  format  is  unnecessary,  except  to  the  extent 
that  it  should  be  in  agreement  with  the  formatting  concept  used 
for  other  types  of  SSR  transactions. 

(5)  Part  Number  Items.  Part  Number  SSR  items 
require  two  transactions  to  contain  all  of  the  data  elements 
required  to  process  these  items.  This  introduces  an  additional 
control  element  -  card  number  -  in  addition  to  those  listed 
under  active  NSN  items  above.  The  card  number  is  used  to  control 
and  sequence  LISSR  transactions  for  these  items.  The  first  card 
format  is  similar  to  the  current  format  for  inactive  NSN  SSR 
items.  The  second  card  format  contains  item  identifying  and 
technical  Information  which  would  not  fit  into  Card  Format  1. 

The  data  elements  which  were  unused  for  inactive  NSN  SSR  items 
are  used  in  processing  part  number  SSR  items  and  cannot  be  simply 
eliminated  from  this  format.  There  is  a  single  data  element  from 
the  second  card  format  which  should  be  eliminated  under  the  sys¬ 
tem  redesign.  The  Technical  Data  Justification  Code  (TDJC)  was 
found  to  be  duplicative  of  the  Document  Availability  Code  (DAC) 
in  the  data  analysis  and  the  assignment  of  the  TDJC  is  predi¬ 
cated  on  the  assignment  of  the  DAC  as  an  editing  feature  of  some 
Components  automated  validation  procedures.  Both  codes  are  not 
required  and  since  the  DAC  is  already  established  as  a  standard¬ 
ized  code  in  the  DIDS  Procedures  Manual  (Appendix  D,  Reference 
25),  the  TDJC  should  be  eliminated. 

(6)  Other  Data  Elements 


There  are  three  other  data  elements  common  to 
the  current  formats  of  SSR  items  which  may  be  eliminated.  These 
data  elements  Include  the  Item  Management  Code,  Procurement 
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Method  Code  and  Interchangeability  Code.  The  Item  Management 
Code  indicates  that  the  SICC  has  coded  the  item  for  management 
to  an  I  MM .  The  Item  Management  Code  was  not  used  in  the  proce¬ 
dures  in  effect  prior  to  implementation  of  the  I  MM  Manual.  The 
submittal  of  a  LISSR  transaction  in  these  procedures  was  assumed 
to  indicate  the  same  thing  as  the  I MC  in  the  I  MM  Manual  proce¬ 
dures.  This  is  a  valid  concept  and  should  be  adopted  under  the 
system  redesign. 

The  Procurement  Method  Code  (PMC)  is  currently 
required  to  be  submitted  for  all  items  except  active  NSN  items. 
There  is  an  additional  code  required  by  DLSC  -  the  Procurement 
Method  Suffix  Code  -  without  which  the  Procurement  Method  Code 
is  meaningless.  Both  these  codes  should  be  determined  by  the 
manager  of  the  item  and  therefore,  the  PMC  should  be  eliminated 
as  an  SSR  transaction  requirement.  The  data  analysis  also  indi¬ 
cated  that  SICCs  are  apparently  entering  a  constant  in  this  data 
element  field  most  the  time. 

The  I n t e r c ht n g ea b i 1 i t y  Code  is  to  be  submitted 
only  in  SSR  change  transactions  which  are  replaced  item/super¬ 
seding  item  combinations.  The  code  entered  in  these  SSR  change 
transactions  is  generally  a  contractor  recommendation.  There 
currently  exists  standard  procedures  within  the  DoD  Standardiza¬ 
tion  Program  for  review  of  items  and  determination  of  inchange¬ 
ability.  The  study  team  feels  that  DoD  Standardization  Program 
procedures  should  be  used  to  determine  the  proper  code  to  be 
used  and  that  this  data  element  should  be  eliminated  from  the 
SSR  transaction  formats  since  there  is  no  evidence  it  is  being 
used  even  when  an  entry  is  made. 

c.  Catalog  Transactions.  There  are  three  cataloging 
transaction  formats  in  the  current  system.  These  include  Item 
Name  Transactions,  Additional  Reference  Number  Transactions,  and 
Additional  User  Transactions.  Each  of  these  transactions  con¬ 
tain  the  basic  data  elements  used  for  sequencing  and  control  as 
described  under  active  NSN  items  above.  Other  than  these  basic 
data  elements,  each  catalog  transaction  provides  a  specific  piec 
of  Information;  e.g.,  the  Additional  User  Transaction  provides 
claimant  provisioning  activities  to  IMMs  so  that  they  may  be 
registered  as  users  of  the  item. 

( 1 )  Item  Name  Transaction 

This  catalog  transaction  is  required  to  be  sub¬ 
mitted  with  Part  Number  SSR  transactions  when  technical  data  is 
not  furnished  with  the  item.  This  transaction  contains  the  item 
name  and  Federal  Supply  Classification  which  along  with  the  data 
from  the  Part  Number  SSR  transaction  provide  the  minimum  informa 
tion  required  for  an  I  MM  to  request  NSN  assignment  from  DLSC.  T 


problems  related  to  this  transaction  were  identified  by  the 
study  team.  First  the  data  analysis  showed  a  significant  number 
of  SSR  transactions  rejected  for  a  lack  of  sufficient  technical 
data.  This  occurs  when  an  item  name  transaction  is  not  sub¬ 
mitted  and  the  submitted  technical  data  does  not  provide  the 
required  information.  The  second  problem  is  the  number  of  LISSR 
package  errors  encountered  as  described  in  the  data  analysis  and 
the  validation  analysis  in  Volume  III.  Under  the  current  system 
submittal  of  an  item  name  transaction  with  each  part  number  SSR 
item  would  reduce  the  first  problem  to  the  extent  that  it  would 
virtually  disappear;  however,  this  would  tend  to  increase  the 
number  of  LISSR  package  errors  encountered  as  the  second  problem 
area.  There  is  a  basis  for  providing  these  item  name  transac¬ 
tions  with  each  part  number  SSR  item  from  the  CIMM  SSR  proce¬ 
dures  in  effect  prior  to  implementation  of  the  IMM  Manual.  In 
addition,  each  of  the  Component  automated  SSR  Applications 
already  produce  item  name  transactions  with  each  part  number 
LISSR  generated;  however,  these  are  discarded  manually  for  items 
submitted  with  technical  data.  Therefore,  under  the  current 
system  item  name  transactions  should  be  submitted  with  each  part 
number  SSR  item  to  reduce  the  number  of  rejects  for  lack  of  suf¬ 
ficient  technical  data  and  the  line  item  package  validation 
described  below  should  be  used  by  both  SICC  and  IMMs  to  reduce 
the  LISSR  package  errors. 

The  useful  data  elements  in  this  transaction 
include  the  item  name  and  FSC.  These  data  elements  should  be 
included  in  the  new  format  for  part  number  transactions  under 
the  system  redesign.  Since  part  number  SSR  items  already  occupy 
two  transaction  formats  and  there  are  a  number  of  vacant  posi¬ 
tions  in  these  transactions,  there  is  no  problem  with  elimi¬ 
nating  the  item  name  transaction  and  combining  the  useful  data 
into  the  part  number  LISSR  formats. 

(2)  Additional  Reference  Transactions.  These  trans 
actions  were  found  to  be  submitted  infrequently  and  that  many  of 
the  submissions  in  the  data  collection  were  the  result  of  a 
system  error  by  a  single  Component  caused  by  misinterpretation 
of  the  IMM  Manual.  The  additional  reference  number  submitted 
requires  manual  review  by  IMMs  to  determine  the  usefulness  and 
applicability  of  this  reference  number  prior  to  initiating  cata¬ 
log  action  to  add  the  item  to  DLSC  files.  Due  to  the  low  volume 
of  these  transactions  and  since  they  are  useful  in  SSR  actions 
only  for  part  number  SSR  items,  these  transactions  should  be 
eliminated  from  the  SSR  procedures  and  the  reference  number 
should  be  included  in  the  part  number  LISSR  format  as  with  the 
item  name  and  FSC  discussed  above.  If  space  is  not  available  in 
this  format,  the  existing  cataloging  procedures  should  be  used 
to  process  additional  reference  numbers. 


(3)  Additional  User  Transactions.  This  transac¬ 
tion  provides  claimant  provisioning  activities  under  joint  pro¬ 
visioning  actions  for  user  recordation  action  by  the  IMM.  This 
transaction  was  found  to  appear  infrequently  in  the  data  analysis 
(Volume  III).  The  Joint  provisioning  action  trend  as  discussed 
in  an  earlier  section  of  this  Chapter  is  toward  each  Component 
provisioning  activity  determining  and  submitting  its  own  SSR 
requirements.  Due  to  this  current  trend  in  joint  provisioning 
processing  and  because  the  IMM  Manual  does  not  provide  for  fur¬ 
nishing  advice  to  these  subordinate  provisioning  activities  by 
either  the  IMM  or  the  Lead  Service,  the  Additional  User  Trans¬ 
action  should  be  eliminated  from  the  SSR  procedures  and  each 
Service  should  submit  its  own  SSR  requirements. 

d.  Technical  Data.  The  technical  data  submitted  to 
IMMs  consists  of  several  types.  This  technical  data  may  be  a 
hard  copy  drawing  or  aperture  card.  It  may  also  be  a  catalog 
page,  a  written  justification  for  sole  source  procurement,  or  a 
sheet  of  paper  providing  unit  of  issue  data  when  a  nondefinitive 
unit  of  issue  is  given  in  the  LISSR  transaction.  This  technical 
data  is  currently  annotated  with  appropriate  control  data  to 
provide  a  means  of  matching  it  up  with  an  SSR  submittal.  This 
control  data  generally  consists  of  PCC,  ISN,  DOR,  ACF.  Although, 
this  data  is  available  to  the  functional  elements  performing 
provisioning  processing,  many  times  this  control  data  is  not 
annotated  on  the  technical  data  until  the  SSR  transactions  have 
been  generated  for  submittal.  In  addition,  some  activities  send 
technical  data  received  to  the  activity  technical  repository  for 
review  and  duplication  as  part  of  File  Establishment;  other 
activities  may  wait  until  SSR  candidates  are  identified  and  SSR 
transaction  are  being  generated  before  sending  the  technical 
data  to  the  technical  repository.  When  technical  data  Is  not 
placed  in  the  technical  repository  until  SSR  candidates  are 
identified,  SSR  transactions  can  experience  internal  processing 
delays  prior  to  submission  while  waiting  for  return  of  technical 
data  from  the  technical  data  repository.  Currently,  the  IMM  is 
required  to  return  submitted  technical  data  when  items  are 
rejected.  When  the  SSR  advice  is  sent  via  AUTODIN  to  the  SICC 
and  the  technical  t'ata  is  returned  by  mail,  there  is  an  unne¬ 
cessary  time  delay  at  the  SICC  activity  while  waiting  for  the 
technical  data  to  arrive.  It  would  appear  that  since  technical 
data  has  been  placed  in  the  technical  repository  prior  to 
sending  It  to  the  IMM,  It  would  be  readily  available  to  the  SICC 
upon  return  of  SSR  advice.  This  appears  to  make  the  need  for 
return  of  technical  data  by  IMMs  unnecessary. 

e .  System  Considerations 

A 8  defined  above  the  basic  inputs  to  the  system  as 
a  whole  include  the  PTD  submitted  by  the  contractor  from  which 
the  SSR  transactions  are  generated  and  transmitted  to  IMMs. 


140 


These  SSR  transactions  and  the  related  technical  data  serve  as 
Inputs  to  the  IMMs .  The  system  characteristic  which  requires 
discussion  here  is  the  transmission  and  receipt  of  these  inputs. 

In  the  current  system  PDSSR,  LISSR  and  Catalog  transactions  are 
mailed  with  the  associated  technical  data  by  SICCs  to  IMMs  for 
processing.  The  data  analysis  In  Volume  III  shows  that  the 
transmission  time  for  mailing  transactions  can  be  over  one  month; 
which  is  far  too  long  for  effective  system  processing.  This 
mailing  of  SSR  transactions  is  based  on  the  package  concept  of 
processing  and,  to  a  lesser  extent,  on  the  annotation  of  SSR 
control  data  on  the  technical  data  prior  to  submission.  The 
analysis  of  the  AUTODIN/TELEFAX  Test  illustrates  that  all  types 
of  SSR  transactions  could  be  submitted  via  AUTODIN  effecting  a 
great  reduction  in  transmission  time.  This  test  also  showed 
that  the  matching  up  of  technical  data  with  the  appropriate  SSR 
item  could  be  accomplished  with  minimal  problems  by  the  IMM  and 
that  certain  processing  actions  could  be  accomplished  on  the  SSR 
transactions  while  awaiting  for  the  technical  data  to  arrive; 
e.g.,  validation  and  catalog  data  screening.  However,  since 
this  test  was  designed  to  test  AUTODIN  transmittal  only,  there 
was  not  a  direct  tie-in  between  the  automated  generation  of  the 
SSR  transactions  and  the  AUTODIN  submission  of  these  transactions. 
The  processing  performed  during  the  test  generally  included  genera 
tion  and  output  of  the  SSR  transactions  as  EAM  cards  by  some 
activities  so  the  control  data  could  be  annotated  on  the  tech¬ 
nical  data  after  which  the  EAM  cards  were  taken  to  the  AUTODIN 
terminal  for  submission  while  the  technical  data  was  mailed. 
Although  using  this  processing  technique  still  reduces  the  trans¬ 
mission  time  for  SSR  transactions,  the  internal  processing  time 
at  the  SICC  activity  remains. 

The  study  team  has  concluded  that  the  results  of  the 
AUTODIN  Test  clearly  show  that  all  SSR  transactions  should  be 
submitted  via  AUTODIN  and  that  this  transmission  should  be  a 
direct  follow-on  from  the  automated  SSR  Application.  This  may 
be  accomplished  directly  where  an  automated  link  exists  between 
the  computer  and  AUTODIN  terminal  or  indirectly  by  placing  the 
SSR  transactions  on  an  intermediate  disk  or  magnetic  tape  file 
which  is  then  transferred  to  the  AUTODIN  terminal.  This  process 
eliminates  both  the  internal  SICC  processing  time  and  the  mail 
transmission  time.  This  concept  also  affects  the  submittal  of 
technical  data.  For  provisioning  projects,  the  control  data  to 
be  annotated  on  technical  data  is  present  during  the  provisioning 
processing  except  for  the  DOR.  This  control  data  -  ACF ,  PCC, 

ISN  -  should  be  annotated  on  the  technical  data  during  the  pro¬ 
visioning  process.  This  would  allow  functional  elements  like 
the  Data  Management  Branch  at  TSARCOM  in  the  Army  to  mail  the 
technical  data  immediately  rather  than  filing  this  technical 
data  to  await  generation  and  output  of  SSR  transactions  on  EAM 
cards.  For  SSR  transactions  manually  generated  from  sources 
other  than  provisioning  projects,  this  control  data  can  be 
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entered  on  the  technical  data  prior  to  inputting  the  SSR  trans¬ 
actions  to  the  Component  automated  SSR  application  for  valida¬ 
tion,  file  maintenance  and  transmittal  to  the  IMM.  Note  that 
under  the  single  PCC  -  ISN  combination  for  a  single  ACF  concept 
described  under  active  NSN  items  above,  the  DOR  is  no  longer  re¬ 
quired  to  match  up  technical  data  with  the  proper  LISSR  transac- 
t ions  . 

4.  Files  .  The  type,  number,  sequence,  content,  retention 
and  inquiry  capability  of  files  in  the  current  system  were  dis¬ 
cussed  earlier  in  this  Chapter  and  in  Volumes  II  and  III.  All 
of  these  characteristics  were  found  to  vary  among  Components/ 
Activities  and  this  variation  has  resulted  in  communication 
problems  between  activities.  These  communication  problems  have 
resulted  in  match/duplicate  rejects  and  No  Record  responses  to 
followups.  It  would  not  be  effective  to  alter  the  current  files 
under  the  current  system  to  allow  efficient  and  meaningful  com¬ 
munication  between  activities;  however,  under  a  system  redesign 
each  of  these  file  characteristics  could  be  improved  to  provide 
the  desired  basis  for  communication. 

a.  Types/Number.  The  basic  types  of  files  found  to  be 
maintained  for  SSR  items  include  active  files,  suspense  files 
and  history  files.  These  are  maintained  at  both  SICC  and  IMM 
activities  on  both  a  manual  and  automated  basis  at  those  activi¬ 
ties  where  automated  SSR  Applications  exist.  Manual  files 
generally  consist  of  two  types;  a  combination  ac t i ve / sus pens e 
file  and  separate  history  file.  There  may  be  one  or  more  of 
each  of  these  types  maintained.  There  is  generally  a  single 
automated  file  which  acts  as  an  active,  suspense  and  history 
file  combined.  There  is  one  exception  to  this;  DLA  maintains 
separate  automated  files  for  active  items  and  completed  items. 
These  various  types  and  numbers  of  files  were  shown  to  be  a 
direct  outgrowth  of  inconsistences  within  the  IMM  Manual  in  the 
audit  trail  requirements. 

b.  Sequence.  The  study  team  found  that  generally  the 

same  control  elements  and  sort  keys  used  for  sequencing  and  con¬ 
trol  of  processing  are  also  used  to  sequence  both  automated  and 
manual  files.  Manual  files  were  found  to  use  fewer  data  elements 
for  sequencing  and  control  than  automated  files.  As  discussed 
earlier  in  this  Chapter  and  as  documented  in  Volume  II,  the 
actual  data  elements  used  and  the  sequence  in  which  they  appear 
vary  from  Component  to  Component.  This  variance  has  caused  the 
ua t ch  /  dup  1  i ca t e  reject  problem  experienced  in  the  data  analysis. 
It  concluded  in  the  Inputs  Section  above  that  a  control  num¬ 

ber  ^  ining  established  control  data  elements  positioned  in  a 
logical  quence  should  be  made  a  part  of  each  SSR  transaction 
format  under  a  system  redesign  concept.  This  control  number 
should  be  used  for  sequencing  and  controlling  the  storage  and 
maintenance  of  SSR  transactions  in  both  manual  and  automated  SSR 
files.  The  use  of  this  control  number  provides  a  basis  for 
effective  automated  communication  between  SICCs  and  IMMs. 
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c.  Contents .  The  contents  of  manual  versus  automated 
SSR  files  varies  cTTs’tinctly  among  and  within  activities.  While 
manual  files  generally  contain  a  record  of  all  items  submitted 
whether  under  process  or  completed,  invalid  or  valid,  initial 
submission  or  change,  provisioning  or  nonprovisioning;  automated 
files  contain  only  a  portion  of  these  items.  The  automated  file 
contents  vary  among  the  Components,  One  example  of  this  varia¬ 
tion  is  posting  of  valid  versus  invalid  SSR  transactions  to  auto¬ 
mated  files  as  described  in  the  validation  analysis  in  Volume 
III.  Another  example  is  the  posting  of  SSR  change  transactions 
to  the  automated  SSR  files.  The  distinction  here  is  that  SICCs 
generally  post  these  transactions,  while  DLA  posts  only  super¬ 
seding  items.  This  variance  in  contents  is  again  caused  by  a 
lack  of  direction  from  the  IMM  Manual  in  audit  trail  requirements. 
The  appropriate  audit  trail  for  this  system  requires  maintaining 

a  record  of  all  actions  generated  or  received  for  each  item.  At 
a  minimum  this  record  must  contain  the  original  SSR  data,  the 
advice  generated  and  the  date  of  that  advice,  and  all  subsequent 
actions  including  followups,  followup  responses,  offer  replies, 
and  all  changes  to  the  original  SSR. 

d.  Retention/Purge.  The  length  of  time  items  remain 
in  files  vary;  however,  the  basis  for  purging  items  from  these 
files  is  generally  the  same.  Manual  history  files  are  generally 
maintained  for  two  years  after  the  PCC  is  completed  by  all  Com¬ 
ponents.  This  allows  matching  of  SSR  change  transactions  to 

the  original  item.  The  IMM  Manual  allows  SSR  changes  to  be  sub¬ 
mitted  for  24  months  following  the  date  of  request  of  the  ini¬ 
tial  submittal.  Automated  files  contain  a  record  of  completed 
items  for  varying  lengths  of  time  -  generally  180  days  to  one 
year  depending  on  the  Component.  The  IMM  Manual  requires  the 
IMM  to  maintain  a  record  of  advice  for  120  days  following  the 
date  of  advice.  This  is  the  only  reference  found  relating  what 
should  be  maintained  and  how  long  it  should  be  maintained  in  the 
IMM  Manual.  Items  are  generally  purged  from  both  manual  and 
automated  files  on  a  PCC  not  an  item  basis.  Based  on  current 
and  future  requirements,  a  record  of  completed  items  should  be 
maintained  for  two  years  after  completion  of  the  last  action  on 
a  PCC. 


e.  Inquiry  Capability.  To  efficiently  and  effectively 
process  SSR  transactions,  access  to  both  active  and  history  files 
is  required.  This  is  especially  true  where  automated  files  exist 
and  communication  is  required  between  those  files  and  either  an 
internal  or  external  source.  External  sources  fall  under  the 
category  of  SSR  followup  transactions  which  are  discussed  in  the 
section  on  controls  below.  Internal  sources  are  functional  ele¬ 
ments  generating  inquiries  to  obtain  file  information.  Currently 
the  automated  SSR  Applications  generally  provide  for  inquiries 
on  a  PCC  or  an  item  basis.  These  inquiries  are  input  and  pro¬ 
cessed  with  all  other  input  in  the  normal  processing  cycle.  The 
study  team  found  that  the  type  of  inquiries  available  to  functional 
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users  are  sufficient,  but  that  a  mass  inquiry  capability  based 
on  weapon  system  or  end  item  would  also  be  beneficial.  There 
does  exist  a  problem  in  obtaining  inquiry  results  and  this  is 
related  to  the  automated  processing  cycles  discussed  earlier. 

The  current  processing  cycles  allow  for  too  much  time  to  pass 
between  inquiry  submittal  and  inquiry  response  for  efficient  pro¬ 
cessing  to  occur.  The  most  desirable  inquiry  processing  would 
include  inquiry  input  by  the  functional  user  to  an  on-line  system 
capable  of  immediately  processing  the  inquiry  against  the  auto¬ 
mated  SSR  files  and  returning  the  results.  This  capability  does 
not  currently  exist  at  any  SICCs  or  IMMs  to  the  knowledge  of  the 
study  team  and  may  not  be  feasible  at  some  activities  due  to  the 
low  volume  of  SSR  transactions  processed.  The  minimum  acceptable 
inquiry  processing  cycle  is  24  hours  or  on  a  daily  basis.  For 
most  Components  this  requires  only  a  change  in  the  execution  of 
the  daily  processing  cycle  from  two  to  three  times  weekly  to 
daily  as  recommended  by  the  system  design  activities  of  most 
Components . 

f.  Summary .  The  discussion  of  existing  files  is  cen¬ 
tered  around  the  types,  number,  sequence,  contents,  retention, 
and  inquiry  capability  as  characteristics.  The  changes  required 
are  too  extensive  to  be  easily  accomplished  under  the  current 
system.  A  system  redesign  should  provide  files  having  the 
following  characteristics. 

(1)  A  single  automated  file  should  be  •  intained  as 
a  combination  active/suspense/history  file.  Manual  les  should 
be  eliminated  or  exist  on  an  active  item  basis  only. 

(2)  All  SSR  files  maintained  should  be  sequenced  on 
the  SSR  document  control  number  established  as  part  of  the  new 
formats  . 

(3)  An  automated  record  of  all  ac  ions  on  an  Leu 
basis  should  be  maintained.  Active  manual  files  should  contain 
only  the  information  required  to  process  the  current  action. 

(4)  The  automated  file  should  maintain  a  record  of 
items  on  a  PCC/ACF  basis  for  two  years  following  completion  of 
the  last  action  within  that  PCC/ACF  combination.  Active  manual 
files  should  be  discarded  upon  completion  of  the  current  action. 

(5)  Inquiries  should  be  available  to  the  automated 
SSR  file  on  an  item,  PCC  or  weapon  system/end  item  basis  and 
should  be  processed  on  a  daily  basis  so  that  inquiry  results  are 
available  to  the  functional  user  within  24  hours  of  submittal. 
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Processing 


a.  General 


This  section  is  divided  into  three  subsections  for 
discussion.  These  subsections  are  keyed  to  the  Conceptual 
Systems  Model  and  include: 

*  SICC  SSR  GENERATION  PROCESSING 

*  IMM  SSR  PROCESSING 

*  SICC  SSR  ADVICE  PROCESSING 

The  discussion  within  each  subsection  is  based  on  the  major 
events  where  system  problems  were  found  to  exist.  There  are  two 
major  events  which  were  reviewed  by  the  study  team  in  terms  of 
how  they  interface  with  SSR  processing  only.  These  two  major 
events,  Method/Level  of  Support  and  Requirements  Determination, 
were  excluded  from  the  scope  of  the  DODSSR  Study  and  are  there¬ 
fore  not  discussed  in  this  section;  however,  they  are  addressed 
in  the  Policy  Review  Section  of  Part  2  of  this  Chapter. 

There  are  three  major  problem  areas  around  which  the 
overall  discussion  in  this  section  is  centered.  These  major 
problem  areas  include  the  number  and  kinds  of  reject  advice,  the 
varying  interpretation  of  the  current  ATCs  by  SICCs  and  IMMs, 
and  the  number  of  current  ATCs  provided  in  the  IMM  Manual.  In 
the  data  analysis,  the  ATCs  currently  available  were  categorized 
by  the  study  team.  The  reject  category  included  several  subcate¬ 
gories  and  each  major  category  or  subcategory  contained  several 
ATCs.  The  study  team  found  that  although  the  IMM  Manual  contains 
no  categorization  of  these  ATCs,  the  Components  had  at  a  minimum 
categorized  these  ATCs  into  three  categories  -  Accept,  Offer  and 
Reject.  The  particular  ATCs  within  these  categories  and  the  re¬ 
sulting  actions  were  not  consistent  among  activities.  An  example 
of  this  inconsistency  is  illustrated  by  the  categorization  of 
ATC  'YB.'  This  ATC  is  given  for  an  item  which  is  to  be  purchased 
locally  by  using  activities.  The  Services  generally  include  this 
ATC  in  the  accept  category,  while  DLA  considers  it  a  reject. 

The  definition  of  this  ATC  indicates  proper  cataloging  action 
should  be  initiated  to  add  the  SICC  activity  as  a  user  of  the 
item;  however,  the  activity  -  SICC  or  IMM  -  to  take  this  action 
is  not  defined.  The  definition  of  many  ATCs  in  the  IMM  Manual 
caused  this  interpretation  problem.  The  number  of  ATCs  provided 
in  the  IMM  Manual  also  caused  problems  on  both  a  functional  and 
an  automated  processing  basis.  The  study  team  found  that  from 
the  functional  user  standpoint  there  were  too  many  ATCs  to  re¬ 
member  and  that  many  of  the  ATCs  had  overlapping  definitions  - 
particularly  those  within  the  same  reject  subcategories  devel¬ 
oped  by  the  study  team.  The  findings  from  the  automated 
systems  standpoint  was  exactly  opposite  in  that  there  were  not 
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enough  specific  codes  to  identify  exact  validation  error  con¬ 
ditions  in  SSR  transactions.  This  led  to  the  development  of 
Component  unique  reject  codes  as  discussed  in  the  validation 
analysis.  These  problems  led  the  study  team  to  conclude  that 
the  current  ATC  concept  and  method  of  providing  advice  requires 
extensive  revision.  The  particular  revisions  required  are  dis¬ 
cussed  in  the  subsection  below. 

( 1 )  SICC  SSR  Generation  Processing 

The  sources  of  SSR  transactions  include  the  PTD 
from  provisioning  projects,  item  recommendations  from  field 
activities,  and  design  change  notices  among  others.  Each  of 
these  sources  contains  the  data  which  serves  as  the  basis  for 
each  SSR  transaction  and  although  this  data  is  in  many  cases  a 
recommendation  from  the  originator,  e.g.,  contractor  recommended 
data  in  the  PTD;  it  is  usually  transferred  unchanged  to  the  SSR 
transaction.  A  complete  and  thorough  review  of  origination 
documentation  to  ensure  the  data  furnished  is  valid  and  in  the 
proper  format  for  each  data  element,  should  be  done  so  that 
valid  data  is  entered  in  SSR  transactions  generated  from  these 
originating  documents.  For  Components  which  have  automated 
provisioning  systems  much  of  this  review  and  validation  for 
provisioning  projects  may  be  accomplished  on  an  automated  basis. 
Other  source  documents  may  require  a  totally  manual  review. 

The  processing  of  technical  data  by  SICC  activ¬ 
ities  has  an  impact  on  SSR  processing  as  a  whole.  The  study 
team  found  that  technical  data  processing  varies  among  SICC 
activities.  The  technical  data  which  is  to  be  lodged  in  the 
SICC  technical  data  repository  is  the  primary  consideration  here. 
At  some  SICC  activities  this  technical  data  is  forwarded  to  the 
technical  data  repository  for  review,  duplication,  and  storage 
immediately  upon  receipt,  while  other  SICC  activities  may  not 
forward  this  technical  data  to  the  respository  until  the  SSR 
transactions  are  prepared  for  forwarding  to  the  IMMs.  This 
concept  of  duplication  and  storage  of  technical  data  during  SSR 
processing  and  the  requirement  for  return  of  technical  data  by 
IMMs  to  SICCs  as  currently  provided  for  in  the  IMM  Manual  tend 
to  create  delays  in  both  SSR  submission  and  receipt  of  final 
advice.  This  requirement  to  return  technical  data  serves  to 
delay  final  advice  on  some  part  number  SSR  items  in  the  current 
system.  An  example  to  illustrate  this  delay  is  the  case  where 
part  number  SSR  transactions  are  submitted  to  an  IMM  with  a 
hard  copy  drawing  or  aperture  card  serving  as  technical  data. 

If  this  part  number  SSR  item  Is  found  to  contain  invalid  data, 
it  is  rejected  by  the  IMM  and  a  reject  advice  transaction  is 
generated  and  transmitted  to  the  SICC  via  AUTODIN.  The  tech¬ 
nical  data  must  be  mailed  back  to  the  SICC  for  rejected  SSR 
items  as  required  by  the  IMM  Manual.  When  this  technical  data 
Is  required  to  determine  the  correct  data  to  be  entered  on  the 
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SSR  resubmittal  and  the  SICC  has  not  retained  a  copy  of  this 
technical  data  either  in  the  functional  area,  the  SICC  usually 
waits  until  he  receives  the  technical  data  returned  by  the  IMM 
before  he  ""akes  the  required  correction  even  though  a  copy 
could  be  obtained  from  the  technical  data  library.  This  tech¬ 
nical  data  must  then  be  again  submitted  to  the  IMM  with  the  SSR 
resubraittal.  With  the  AUTODIN  submittal  of  all  SSR  transactions 
as  recommended  in  the  discussion  of  Inputs  above,  the  mailing 
again  delays  processing  of  the  SSR  resubmittal  -  this  time  the 
IMM  is  delayed  until  the  technical  data  is  received.  The  pro¬ 
cessing  flow  could  be  greatly  improved  if  both  SICCs  and  IMMs 
would  forward  technical  data  to  the  activity  technical  data 
repository  for  review,  duplication  and  storage  when  it  is  ini¬ 
tially  received  and  that  copies  be  requested  from  the  activity 
technical  repository  when  required.  This  would  elmininate  the 
requirement  for  IMMs  to  return  technical  data  and  the  require¬ 
ment  for  SICC  to  submit  technical  data  with  SSR  re s ubra i 1 1 a  1 s  . 

(a)  Catalog  Data  Screening.  Each  of  the 
SICCs  reviewed  perform  catalog  data  screening  on  all  SSR  items. 
This  screening  may  be  performed  against  local  files  only,  or 
against  both  local  files  and  DISC  files,  or  against  DLSC  files 
only.  The  Navy  and  Air  Force  provide  for  some  automated  pro¬ 
cessing  based  on  the  results  of  this  screening,  and  the  Army 
has  integrated  catalog  data  screening  in  its  automated  provi¬ 
sioning  system.  The  concepts  of  integrating  catalog  data 
screening  into  automated  provisioning  system  and/or  automated 
SSR  applications  (e.g.,  Air  Force)  and  automating  the  pro¬ 
cessing  of  screening  replies  are  good.  The  data  analysis, 
however,  indicates  too  many  rejects  occur  from  submission  of  SSR 
transactions  to  the  wrong  activity  or  submitting  SSR  trans¬ 
actions  for  nonstandard  items  or  for  part  number  items  when 
standard  items  or  stock  numbers  exist.  The  SICCs  should  perform 
quality/timely  catalog  data  screening  to  reduce  the  occurrence 
of  these  erroneous  SSR  submissions.  A  training  course  should  be 
provided  by  DLSC  for  those  activities  not  familiar  with  the  full 
range  of  data  available  from  screening  processes  and  the  inter¬ 
pretation  of  that  data. 

(2)  Validation.  The  validation  conventions 
and  criteria  used  by  the  SICCs  were  discussed  in  the  validation 
analysis.  The  conventions  and  criteria  were  generally  found  to 
differ  between  the  Services  as  SICCs  and  among  the  Components 
as  I MM 8 .  These  differences  were  found  to  be  causing  invalid 
data  rejects  on  an  IMM  basis  for  transactions  which  were  vali¬ 
dated  and  found  to  be  valid  by  SICCs.  This  requires  the  same 
criteria  and  conventions  to  be  used  by  all  SICCs  and  IMMs. 

These  conventions  and  criteria  are  discussed  further  under  IMM 
SSR  processing  below.  The  Navy  and  Air  Force  were  found  to 
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have  designed  multiple  validation  concepts  into  their  respec¬ 
tive  automated  SSR  applications.  This  concept  of  multiple 
validation  of  outgoing  SSR  transactions  by  SICCs  is  a  good  one 
and  should  be  considered  for  continuance  or  adoption  in  any 
system  redesign  projects  of  Component  SSR  applications.  The 
study  team  encountered  the  situation  where  some  SSR  transac¬ 
tions,  like  manually  generated  nonprovisioning  SSR  transactions 
and  SSR  change  transactions  resulting  from  design  change  noti¬ 
ces,  were  not  being  entered  into  Component  SSR  applications  for 
validation  prior  to  submittal.  The  study  team  feels  that  all 
SSR  transactions  should  be  extensively  validated  prior  to  sub¬ 
mittal  and  by  bypassing  this  validation  -  particularly  where 
automated  systems  exist  to  perform  this  event,  SICCs  are  increas 
ing  the  odds  of  these  transactions  being  rejected  for  invalid 
data  and  thus  extending  the  time  before  final  advice  is  received 

(c)  File  Maintenance.  File  maintenance  pro¬ 
cessing  within  SSR  generation  activities  consists  primarily  of 
posting  SSR  transactions  to  automated  and/or  automated  files. 

The  study  team  has  concluded  in  the  section  discussing  files 
above  that  all  types  of  SSR  transactions  should  be  maintained 
in  a  single  file,  preferably  automated,  to  provide  needed  con¬ 
trol  over  processing  of  these  items.  The  skeleton  SSR  transac¬ 
tions  provided  for  invalid  SSR  transactions  in  the  Navy  auto¬ 
mated  system  design  is  seen  to  be  a  concept  worthy  of  considera¬ 
tion  by  other  Components. 

(2)  IMM  SSR  Processing.  The  discussion  of  IMM  SSR 
processing  centers  around  the  five  major  events;  validation, 
catalog  data  screening,  advice  decision,  file  maintenance,  and 
catalog  actions.  Each  major  event  comprises  a  subsection  below. 

(a)  Validation .  The  discussion  of  validation 
is  based  on  the  data  analysis,  validation  analysis,  and  the  com¬ 
parative  system  analysis.  The  data  analysis  and  validation  ana¬ 
lysis  show  the  major  sources  of  errors,  the  reject  codes  applied 
to  these  errors,  how  often  certain  data  elements  are  used  and 
the  relative  use  and  usefulness  of  these  data  elements,  and  the 
extensive  variation  in  validation  conventions  and  criteria  among 
the  Components.  The  comparative  analysis  shows  the  particular 
SSR  data  elements  used  by  IMMs  to  process  SSR  transactions  and 
produce  advice  to  the  SICCs.  These  analyses  are  the  basis  for 
data  element  elimination  and  subsequent  reformatting  and  re¬ 
orienting  of  SSR  transactions  described  in  the  Inputs  Section 
above.  The  elimination  of  data  elements  and  reorientating/re¬ 
formatting  concepts  described  there  requires  the  development  of 
validation  conventions  and  criteria  to  be  applied  to  these  trans 
actions  . 


1_  Validation  Conventions  and  Criteria. 
Under  the  systems  redesign  concept,  the  reformatted  SSR  transac¬ 
tions  provide  the  basis  for  development  of  these  validation  con¬ 
ventions  and  criteria.  These  new  validation  conventions  and 
criteria  must  be  applied  consistently  among  the  Components  to 
avoid  the  same  types  of  errors  occurring  in  the  current  system 
from  appearing  in  the  system  redesign.  There  are  certain  im¬ 
provements  that  may  be  made  in  the  current  system  to  reduce  the 
prominent  errors  appearing  in  the  current  system.  These  improve¬ 
ments  are  based  on  the  errors  occurring  and  the  data  elements 
used.  The  predominant  errors  occurring  include  package  errors, 
PMC  errors  due  to  the  active  vs  inactive  NSN  item  formats,  and 
errors  due  to  invalid  data  in  data  elements  in  the  other  man¬ 
datory  category. 


£  Package  Validation.  Since  the  PDSSR 
transactions  and  catalog  transactions  are  eliminated  in  the  sys¬ 
tem  redesign,  the  package  validations  involving  these  transac¬ 
tions  should  generally  be  eliminated  from  the  current  system. 
There  is  a  single  package  validation  which  should  be  performed. 
Each  part  number  LISSR  card  number  1  transaction  must  be  accom¬ 
panied  by  a  part  number  LISSR  card  number  2  transaction  and  an 
item  name  transaction. 


t>  Match/ Du  plicate  Validation.  There 
should  be  a  match  of  incoming  LISSR  transactions  against  one 
another  and  against  previous  submissions  to  insure  that  only  one 
valid  LISSR  transaction  is  received  for  the  same  ACF ,  PCC,  and 
ISN  combination.  This  eliminates  the  duplicate  submission  prob¬ 
lem  experienced. 


£  PDSSR  Data  Element  Validation. 

There  are  only  two  useful  data  elements  in  this  transaction  for¬ 
mat.  These  include  the  DRPR  and  Percent  End  Items  East.  The 
DRPR  should  be  validated  and  used  if  valid.  If  invalid,  the  IMM 
should  determine  the  support  date  and  furnish  it  to  the  SICC  on 
Items  accepted  for  support.  The  Percent  End  Items  East  should 
be  validated  and  edited  to  a  value  determined  by  the  IMM  when 
invalid . 


d^  NSN  SSR  Data  Element  Validation. 
Based  on  the  elimination  of  the  distinction  between  active  and 
inactive  NSN  items,  the  following  data  elements  should  be  vali¬ 
dated  for  rejection  of  NSN  SSR  transactions: 

Document  Identifier  Code 
Activity  Code  To 
Provisioning  Control  Code 
Item  Serial  Number 
Date  of  Request 
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Activity  Code  From 
NSN 

Replenishment  Quantity 
Retail  Quantity 
Unit  of  Issue 

e_  PSCN  SSR  Data  Element  Validation. 

Due  to  the  low  volume  of  these  type  SSR  transactions,  no  changes 
in  data  element  validation  should  be  made  under  the  current  sys¬ 
tem. 


f_  Part  Number  SSR  Data  Element  Valida¬ 
tion.  Based  on  the  data  elements  used  by  IMMs  to  process  part 
number  items  and  current  validation  criteria  the  following  data 
elements  should  be  validated  for  rejection  of  this  type  SSR 
transaction: 


Document  Identifer  Code 
Activity  Code  To 
Provisioning  Control  Code 
Item  Serial  Number 
Date  of  Request 
Activity  Code  From 
Card  Number 
Retail  Quantity 
Replenishment  Quantity 
Unit  of  Issue 
Production  Leadtime 
Unit  Price 

FSCM/Ref erence  Number 
Reference  Number  Format  Code 
Reference  Number  Category  Code 
Reference  Number  Variation  Code 
Document  Availability  Code 

Since  the  current  system  conclusions  from  the  Inputs  Section 
above  include  submission  of  an  Item  Name  transaction  with  each 
part  number  SSR  item  submitted,  the  item  name  and  FSC  as  well  as 
the  control  data  elements  on  this  type  transaction  should  be 
validated. 


£  Data  elements  to  be  eliminated  in 
the  system  redesign  should  bypass  validation  in  the  current 
system.  These  data  elements  include: 

End  Item  Quantity 
Procurement  Method  Code 
Quantity  Per  End  Item 
Type  Change  Code 
Item  Management  Code 
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Date  NSNs  are  Required 
End  Item  NSN,  Name,  etc. 

Contract  Control  Number 
End  Item  Delivery  Code 
FSCM  Prime 
Weapon  System  Code 

Item  Identification  Data  Receiver 
Item  Identification  Data  Collaborator 
Materiel  Management  Aggregation  Code 
Number  of  SSRs  Enclosed 
MOE  Rule 

Technical  Data  Justification  Code 
Interchangeability  Code 

jn  Any  remaining  data  elements  should 
be  bypassed  or  validated  and  edited  when  invalid  based  on  their 
relative  usefulness.  These  data  elements  may  be  considered  for 
elimination  under  the  systems  redesign  based  on  their  relative 
usefulness  and  the  availability  of  space  in  the  new  transaction 
f  orna t  s . 

2  Communication  of  Invalid  Data.  Invalid 
data  identified  through  validation  is  communicated  externally 
using  reject  advice  transactions  in  the  current  system.  These 
transactions  should  continue  to  be  used  in  the  current  system. 
Under  the  concept  of  system  redesign  and  communication  of  advice 
in  the  system  redesign.  All  rejects  should  be  grouped  into  a 
single  category  and  within  this  overall  reject  category  separate 
subcategories  identified  through  transaction  codes  should  exist 
for  invalid  data  elements  and  for  validation  errors  falling  into 
the  match/duplicate  subcategory.  The  transaction  code  would 
Identify  the  reject  as  an  invalid  data  reject  or  the  particular 
invalid  ma t c h / dup 1 i ca t e  condition  found.  The  data  elements 
found  to  be  in  error  should  be  clearly  identified  using  a  data 
element  number/data  reference  number  technique.  The  validation 
analysis  indicates  that  there  is  some  advantage  to  performing 
multiple  validation  of  SSR  transactions  and  since  there  is  space 
available  in  the  invalid  data  advice  transaction,  the  system 
redesign  should  provide  for  multiple  validation  of  SSR  transac¬ 
tions  and  identification  of  up  to  five  data  elements  in  error  in 
the  reject  transaction.  The  DIO  of  the  SSR  transaction  in  error 
should  also  appear  in  the  invalid  data  reject  advice  transaction 
so  that  all  types  of  SSR  transaction  errors  may  be  communicated 
to  the  submitter  including  LISSR  transactions  and  advice  transac¬ 
tions  . 

( b )  Catalog  Data  Screening 

The  current  system  provides  for  rejecting 
items  when  catalog  data  screening  indicates  certain  conditions 
exist.  These  conditions  include  (1)  catalog  data  screening 


matches  the  submitted  part  number  to  an  existing  NSN/PSCN,  (2) 
catalog  data  screening  indicates  a  standard  NSN/PSCN  exists  for 
the  item  submitted  or  the  submitted  item  has  been  cancelled  and 
replaced  by  another  item,  and  (3)  catalog  data  screening  indi¬ 
cates  the  item  is  managed  by  an  IMM  other  than  the  I  MM  to  which 
the  item  was  submitted  for  support.  There  are  a  number  of  ATCs 
in  the  current  system  pertaining  to  each  of  these  conditions  and 
DLA  has  automated  the  processing  of  DLSC  screening  to  automati¬ 
cally  generate  reject  advice  transactions  containing  an  appro¬ 
priate  ATC  for  each  of  these  conditions.  As  described  above  in 
SICC  SSR  generation  processing,  many  of  these  errors  can  be 
avoided  by  the  SICCs  performing  t i me  1 y / q ua 1  i  t y  catalog  data 
screening.  The  remainder  of  these  rejects  in  the  first  and 
second  conditions  may  also  be  eliminated  in  both  the  current 
system  and  the  system  redesign  concept.  The  third  error  con¬ 
dition  can  be  eliminated  under  the  system  redesign  concept  only. 

Due  to  the  rate  of  occurrence  of  these 
type  errors  as  discussed  in  the  data  analysis  and  the  resulting 
delay  in  processing  experienced  when  these  items  are  rejected  by 
IMMs,  and  subsequently  corrected  and  resubmitted  by  SICCs  in  the 
current  system;  the  following  changes  to  the  current  systems 
should  be  made.  When  the  IMM  matches  a  part  number  to  an  NSN  in 
DLSC  files  through  catalog  data  screening,  the  IMM  should  not 
reject  the  item  but  should  furnish  accept  advice  to  the  SICC  in 
conjunction  with  the  matched  NSN.  The  ATCs  indicating  these 
error  conditions  should  be  eliminated.  When  a  standard  item  or 
replacement  item  is  identified,  the  IMM  should  furnish  advice  to 
the  SICC  undicating  acceptance  of  support  on  the  standard/re¬ 
placement  items.  The  ATCs  in  the  current  system  should  have 
their  definitions  revised  to  indicate  this  acceptance.  When 
DLSC  screening  indicates  the  item  requested  has  been  cancelled 
without  replacement,  the  IMM  should  accept  support  and  take 
action  to  reinitiate  the  item.  The  ATC  definition  applicable 
to  the  condition  should  also  be  altered.  In  all  of  the  cases 
described  above  the  IMM  should  continue  processing  of  the  item 
to  initiate  appropriate  catalog  actions  (e.g.,  add  user  trans¬ 
actions,  NIIN  requests,  etc.).  No  changes  to  the  current  system 
should  be  made  when  catalog  data  screening  indicates  the  item  is 
managed  by  another  IMM. 

In  the  system  redesign,  when  the  submitted 
item  is  matched  in  DLSC  files  or  the  item  is  cancelled  without 
replacement,  these  items  should  be  included  in  the  overall  accept 
category  in  the  subcategory  indicating  the  SICC  will  be  supported 
on  the  item  requested.  Those  items  matched  to  a  standard  item, 
or  replacement  item  should  also  be  included  in  the  accept  cate¬ 
gory,  but  a  separate  subcategory  should  exist  for  these  items. 

The  receiving  IMM  should  alter  the  IMM  activity  in  the  LISSR 
transaction  and  forward  the  item  to  the  managing  IMM  for  pro¬ 
cessing  for  items  which  DLSC  screening  indicates  another  manager. 


152 


Technical  data  for  these  "passed"  items  should  also  be  forwarded 
to  the  managing  IMM  by  the  receiving  IMM.  A  new  advice  trans¬ 
action  reflecting  this  passing  action  should  be  established  in  a 
separate  advice  category.  This  passing  action  advice  should 
contain  the  activity  code  of  the  IMM  to  which  the  item  was  for¬ 
warded  and  should  be  used  to  update  the  SICC  SSR  suspense  file 

to  reflect  the  proper  IMM.  The  transaction  date  for  this  passing 

action  advice  transaction  should  be  used  as  a  basis  for  following 
up  to  the  managing  IMM.  The  receiving  IMM  should  maintain  a 
record  of  receipt  of  the  LISSR  transaction  and  of  the  passing 
action  advice. 

( c )  Advice  Decision 

The  discussion  under  this  major  event  is 
centered  around  advice  decisions  generally  made  on  a  manual 
basis  as  opposed  to  those  resulting  from  the  automated  actions 
associated  with  validation  and  catalog  data  screening  discussed 
above.  This  discussion  is  keyed  to  the  system  redesign  concept 
since  the  changes  required  to  the  current  system  would  be  too 

extensive.  Also,  the  changes  in  this  particular  area  do  not  tend 

to  decrease  the  occurrence  of  rejected  SSR  transactions,  but 
tend  to  make  the  advice  given  more  meaningful  to  the  SICC  and 
provide  that  advice  on  a  more  timely  basis. 

The  advice  decisions  reached  here  result 
from  actions  accomplished  during  item  entry  control  actions  and 
result  in  accept,  offer,  or  reject  advice.  Except  for  the  case 
where  support  is  accepted  on  the  item  submitted  by  the  SICC,  the 
advices  from  item  entry  control  procedures  usually  fall  into  dif¬ 
ferent  subcategories  than  those  discussed  in  validation  and  cata¬ 
log  data  screening  above.  During  item  entry  control,  the  item 
submitted  and  the  associated  technical  data  is  received  to  iden¬ 
tify  if  an  a  1 1 e r na t e / s u b s t i t u t e  item  is  already  in  the  supply 
system  and  may  be  offered  to  the  SICC.  Under  the  current  system, 
when  an  a 1 t e r na t e / s u b s t i t u t e  item  is  identified,  an  offer  advice 
transaction  is  generated  and  transmitted  to  the  SICC  and  a  DLA 
Form  546,  Alternate/Substitute  Item  Referral,  is  prepared  and 
mailed  to  the  SICC.  This  form  serves  as  technical  data  to  aid 
the  SICC  in  making  a  decision  to  accept  or  reject  the  offered 
item.  The  SICC's  decision  is  forwarded  on  an  offer  reply  trans¬ 
action  to  the  IMM.  The  data  analysis  shows  a  very  high  rate  of 
acceptance  when  the  offered  item  is  stock  numbered.  These  offers 
consist  of  two  categories  of  substitute  items.  The  categories 
consist  of  stock  numbered  items  that  are  equivalent  to  the  sub¬ 
mitted  item  in  terms  of  both  performance  and  physical  charac¬ 
teristics  and  are  the  same  item  of  supply,  and  stock  numbered  or 
part  numbered  items  that  are  better  than  the  submitted  item  but 
a  different  item  of  supply.  In  the  first  case  the  reference 
number  submitted  can  be  added  to  the  NSN  in  DLSC  files  as  a  pri¬ 
mary  reference  number,  while  in  the  second  case  they  cannot.  The 
first  of  these  subcategories  should  be  considered  as  a  subcategory 


of  accept.  These  advice  transactions  should  indicate  that  the 
IMM  accepts  support  on  the  substitute  item  identified  and  the 
SICC  need  provide  a  reply  only  if  the  substitute  item  is  not 
acceptable.  The  second  subcategory  should  be  considered  in  the 
same  manner  as  offer  advice  is  today  in  that  a  reply  indicating 
acceptance  or  rejection  of  the  item  is  required.  In  many  cases 
the  DLA  Form  546  accompanying  these  substitute  item  offers  in 
the  current  system  contains  minimal  data  in  addition  to  SSR 
control  information  and  the  offered  item  MSN  or  reference  number. 
This  shows  a  potential  for  eliminating  the  use  of  the  form  as 
technical  data  and  including  the  data  furnished  in  the  substitute 
item  accept  or  offer  advice  transaction.  Including  this  data  in 
the  advice  transaction  would  allow  the  advice  and  technical  data 
to  be  forwarded  over  AUTODIN  and  the  SICC  to  immediately  begin 
processing  to  determine  if  the  offered  item  is  acceptable.  In 
the  current  system  when  the  offer  advice  transaction  is  trans¬ 
mitted  via  AUTODIN,  the  SICC  generally  waits  until  the  DLA  Form 
546  is  received  (by  mail)  before  processing  is  started. 

When  the  original  item  submitted  is  not 
accepted  for  support  and  a  substitute  item  is  not  identified, 
the  SSR  item  is  rejected.  These  rejects  fall  into  three  sub¬ 
categories  -  technical  rejects,  support  rejects  and  other.  These 
three  su be  a t e go r i e s  should  be  maintained  as  separate  reject  sub¬ 
categories  under  the  system  redesign  concept. 

Technical  rejects  indicate  that  certain 
SSR  data  required  to  process  the  item  is  invalid  or  not  avail¬ 
able.  An  example  of  this  situation  is  where  the  submitted  FSCM 
or  part  number  is  improperly  formatted.  The  Components  have 
initiated  action  in  the  current  system  to  allow  DLA  to  correct 
FSCMs  and  part  numbers  which  are  improperly  formatted.  The 
study  team  has  no  data  or  research  to  support  or  refute  this 
action;  however,  since  this  action  has  been  initiated,  a  provi¬ 
sion  for  providing  this  advice  under  the  system  redesign  is 
included.  This  advice  should  be  considered  as  a  separate  sub¬ 
category  of  accept  advice  and  interpreted  as  acceptance  of  sup¬ 
port  by  the  IMM  on  the  reformatted/corrected  part  number  and/or 
FSCM.  However,  a  provision  must  also  be  included  to  allow  the 
SICC  to  reply  to  this  change  indicating  that  the  action  taken  by 
the  IMM  is  improper  and  providing  the  properly  formatted  FSCM/ 
part  number  required  by  the  SICC. 

There  is  an  ATC  (36)  in  the  current  system 
indicating  Other  advice;  i.e.,  no  other  ATC  applies.  In  many 
cases  these  "other"  rejects  are  accompanied  by  a  DLA  Form  546 
indicating  the  cause  of  the  reject  advice.  The  data  analysis 
indicates  that  this  code  Is  used  for  a  variety  of  error  condi¬ 
tions  that  occur  in  the  current  system.  A  reject  subcategory 
Indicating  the  SSR  item  is  rejected  for  a  reason  not  covered  in 
the  other  reject  subcategories  is  required.  This  reject  subcate¬ 
gory  should  be  constantly  monitored  to  ensure  it  is  not  to  used 
to  reject  SSR  items  which  fall  under  another  reject  subcategory. 
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In  addition,  the  other  reject  transaction  format  should  provide 
space  for  an  alphanumeric  "in  the  clear"  message  to  provide  the 
reason  for  the  reject,  thereby  eliminating  the  need  to  provide 
the  actual  reason  using  a  DLA  Form  5  4  6  or  other  correspondence 
which  must  be  transmitted  by  mail. 

( d )  File  Maintenance 


The  type  of  SSR  transactions  to  be  main¬ 
tained  to  provide  an  adequate  audit  trail  is  discussed  in  the 
subsection  dealing  with  files  above.  This  discussion  centers 
around  when  file  maintenance  actions  should  occur  and  how  they 
should  be  accomplished  in  automated  SSR  applications.  Each  SSR 
item  should  be  established  in  the  SSR  suspense  file  -  whether 
automated  or  manual  -  immediately  upon  receipt  by  the  I  MM .  All 
subsequent  actions  should  then  serve  to  update  this  basic  record 
including  validation,  catalog  data  screening  and  all  other  ac¬ 
tions  taken  on  an  automated  or  manual  basis  by  IMMs.  When  an 
advice  decision  is  readied,  the  advice  should  be  posted  to  the 
item  record  prior  to  generation  of  advice  transactions  to  be 
transmitted  to  the  SICC.  When  SSR  transactions  are  received 
from  SICCs  which  relate  to  a  previous  submission;  i.e.,  SSR 
change  transactions,  reply  transactions,  followup  transactions, 
etc.;  these  transactions  should  be  matched  to  the  SSR  suspense 
file  using  the  SSR  document  control  number  (under  system  rede¬ 
sign  concept)  and  posted  to  the  matched  item  record  immediately 
upon  receipt.  Unmatched  transactions  of  this  type  fall  into  the 
match/duplicate  reject  subcategory. 

In  the  automated  SSR  applications  designed 
by  the  Components  to  accommodate  the  current  system  requirements, 
two  methods  of  file  maintaining  SSR  actions  are  used.  One  method 
provides  for  inputting  SSR  transactions  to  be  returned  to  SICCs; 
e.g.,  advice  transactions;  directly  to  the  SSR  application  for 
posting  to  the  SSR  suspense  file.  This  requires  manual  genera¬ 
tion  of  the  advice  transactions  in  the  I  MM  Manual  format  prior 
to  introducing  them  to  automated  processing.  These  automated 
SSR  applications  generally  produce  a  duplicate  of  the  input  trans 
action  for  transmittal  to  the  SICC  after  the  file  maintenance 
actions  are  completed.  In  some  cases,  the  study  team  found  that 
a  duplicate  of  the  advice  transaction  was  produced  and  trans¬ 
mitted  to  the  SICC  prior  to  introducing  the  original  advice  trans 
action  to  the  automated  system  for  validation  and  file  mainte¬ 
nance.  The  second  method  provides  for  generation  of  skeleton 
file  maintenance  transactions  when  SSR  items  are  output  for 
manual  review.  This  method  requires  only  the  advice  decision 
and  related  data;  e.g.,  the  item  identifier  of  a  substitute  item 
offer  to  be  entered  in  the  file  maintenance  transaction.  When 
the  file  maintenance  transaction  is  entered  into  the  automated 
system  for  processing,  the  file  maintenance  actions  are  accomp¬ 
lished  and  the  appropriate  advice  transactions  are  automatically 
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generated.  This  second  method  of  using  skeleton  file  maintenance 
transactions  should  be  adopted  by  all  Components  in  the  automated 
system  redesign.  It  provides  a  better  control  over  manual  actions 
and  more  timely  manual  processing  through  simplification  of  the 
manual  processing  required  to  generate  advice  transactions. 

( e )  Catalog  Actions 

The  catalog  actions  which  predominate  in 
processing  SSR  items  are  IMC  actions,  add  user  actions,  NIIN 
request  actions,  and  to  a  lesser  extent  reactivation  of  inactive 
items  and  reinstatement  of  cancelled  items.  The  responsibility 
of  performing  these  cataloging  actions  rests  with  the  managing 
IMM  regardless  of  the  method  of  management  or  level  of  support 
provided.  The  changes  in  the  current  system  described  above  as 
well  as  the  system  redesign  concept  requires  IMMs  to  perform 
catalog  actions  to  add  SICC  activities  as  users  on  standard  and 
replacement  items,  and  to  reinstate  items  cancelled  without  re¬ 
placement,  since  these  items  are  shifted  ^om  the  reject  advice 
category  to  the  accept  advice  category. 

There  is  a  significant  change  required  in 
NIIN  requests  generated  by  IMMs.  This  change  stems  from  the  NIIN 
assignment  process.  Currently  NIIN  assignment  requests  to  DLSC 
contain  a  submitter  control  number  assigned  by  and  recognizable 
only  to  the  IMM  making  the  request.  When  the  NIIN  is  assigned 
by  DLSC  it  is  broadcast  to  the  requesting  IMM  and  the  registered 
users  (the  SICC  activity)  at  the  same  time.  Upon  receipt  of  the 
broadcast,  the  IMM  generates  an  NSN  notification  for  transmittal 
to  the  SICC  activity.  The  SICC  must  currently  wait  until  the 
NSN  notification  is  received  and  processed  before  he  can  match 
the  NIIN  assignment  broadcast  by  DLSC  to  provisioning,  SSR  or 
other  ICP  files.  With  the  adoption  of  the  PCC/PLISN  concept 
described  in  the  inputs  subsection  above,  this  situation  can  be 
easily  remedied.  When  a  single  PCC  and  PLISN  within  a  SICC 
activity  are  used  to  identify  a  single  support  item,  these  SSR 
control  elements  can  be  combined  to  form  the  submitter  control 
number  in  the  NIIN  request  to  DLSC.  Then  when  the  NIIN  assign¬ 
ment  is  broadcast  by  DLSC,  the  submitter  control  number  can  be 
used  to  match  the  broadcast  to  the  SSR  suspense  file  by  SICC 
activities.  This  would  allow  SICCs  to  identify  immediately  the 
item  to  which  the  NIIN  assignment  applies  and  thereby  update 
provisioning  and  other  local  ICP  files  on  a  more  tir-ly  basis. 

(3)  SICC  SSR  Advice  Processing.  The  discussion  of 
SICC  SSR  advice  processing  centers  around  four  major  events  - 
validation,  advice  review,  file  maintenance,  and  notification 
actions.  Actions  relating  to  each  of  these  major  events  are 
described  below. 


(a)  Validation.  The  validation  analysis  indi¬ 
cates  many  advice,  offer  reply ,  followup  and  followup  response 
transactions  are  submitted  containing  invalid  or  missing  data. 

The  current  system  provides  no  means  of  communicating  these 
errors  to  the  transaction  submitter  except  for  offer  reply  trans¬ 
actions.  Many  Components  have  developed  internal  reject  codes 

to  be  able  to  communicate  with  the  functional  user  that  an  in¬ 
valid  LIAC  transaction  has  been  received  and  the  particular 
error  or  errors  found.  The  functional  user  must  then  initiate 
manual  action  to  determine  all  of  the  information  that  was  sup¬ 
posed  to  be  provided  in  the  LIAC.  The  invalid  data  reject  sub- 
category  discussed  in  IMM  SSR  processing  above  and  the  type  of 
reject  advice  transaction  described  for  the  system  redesign 
would  allow  the  same  transaction  to  be  used  to  reject  all  types 
of  SSR  transactions  not  just  LISSR  transactions  as  is  the  situa¬ 
tion  in  the  current  system.  The  Component  system  redesign  should 
provide  for  validation  of  all  outgoing  and  incoming  SSR  transac¬ 
tions  and  provide  for  rejecting  all  SSR  transactions  submitted 
with  invalid  or  missing  data. 

( b )  Advice  Review 

Eliminating  the  concept  of  using  a  single 
DIC  for  all  advice  transactions  and  different  ATCs  to  indicate 
type  of  advice  and  adoption  of  the  system  redesign  concept  which 
uses  different  DICs  for  each  major  advice  category  and  transac¬ 
tion  codes  within  DICs  to  identify  advice  subcategories  will 
make  the  advice  review  process  easier  to  perform.  The  combina¬ 
tion  of  DIC  and  transaction  code  will  clearly  identify  the  type 
of  advice  and  will  indicate  the  actions  required  by  the  SICC. 

This  will  enable  SICCs  to  identify  advice  which  requires  review 
and  generation  of  a  resubmission,  and  advice  for  which  an  accept/ 
reject  decision  must  be  made  and  a  resulting  reply  transaction 
generated  for  transmission  to  the  IMM. 

In  the  current  system  when  a  new  support 
date  Is  provided  to  a  SICC  by  an  IMM,  the  SICCs  have  the  option 
of  procuring  part  or  all  of  the  retail  quantity  to  meet  require¬ 
ments  existing  before  the  new  support  date.  These  quantities 
are  usually  purchased  by  the  SICC  from  the  end  item  manufacturer. 
Currently,  SICCs  are  not  required  to  provide  the  quantity  pur¬ 
chased  to  the  IMM.  SICCs  should  provide  this  intelligence  to 
the  I MM 8  to  allow  the  IMMs  to  more  accurately  forecast  the  ini¬ 
tial  requirements.  SSR  change  transactions  should  be  used  to 
communicate  this  information  to  the  IMM. 

(c)  File  Maintenance.  All  types  of  advice 
transactions  should  be  matched  to  the  SSR  suspense  file  on  the 
SSR  control  number  and  posted  to  the  appropriate  item  record. 

When  a  match  is  not  found  the  advice  transaction  should  be 
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rejected  as  a  match/dup licate  reject.  The  Component  automated 
system  redesign  should  provide  for  generation  of  skeleton  file 
maintenance  transactions  when  a  reply  or  resubmission  is  required. 
This  skeleton  file  maintenance  transaction  would  be  used  to  update 
the  automated  SSR  suspense  file  and  generate  the  appropriate 
transactions  for  transmittal  to  the  IMM. 

(d)  Notification.  In  the  current  system,  noti- 
tifications  of  final  acceptance  or  rejection  are  performed  on  a 
manual  basis.  These  notifications  go  to  the  provisioner  or  SSR 
candidate  originator  who  must  then  take  manual  action  to  update 
provisioning  and/or  local  ICP  files  with  support  data,  assigned 
NSNs ,  etc.  The  Air  Force  is  the  only  SICC  which  has  attempted 
to  automate  communication  directly  between  its  automated  provi¬ 
sioning  system  and  its  automated  SSR  application.  This  two-way 
interface  was  described  in  Volume  II.  In  the  Component  system 
redesign,  each  SICC  Component  should  develop  an  automated  feed¬ 
back  of  SSR  final  advice  to  the  Component  automated  provisioning 
system  when  one  exists. 

6.  Outputs .  The  discussion  of  outputs  is  divided  into  three 
subsections  to  address  external  outputs,  internal  outputs,  and 
output  system  considerations. 

a.  External  Outputs.  There  are  no  changes  to  the  ex¬ 
ternal  outputs  in  the  current  system.  The  system  redesign  calls 
for  a  complete  reorientation  of  advice  and  reply  transactions. 
These  transactions  are  listed  by  subcategory  within  major  cate¬ 
gory  below. 

*  Accept  Category 

Accept  item  requested 

Accept  standard/replacement  item 

Accept  substitute  item 

Accept  FSCM/ re f erence  number  change 

*  Offer  Category 

-  NSN/PSCN  offer 

Part  number  offer 

*  Reject  Category 

Invalid  data  reject 
Match/duplicate  reject 
Technical  reject 
Suppor  t  re  jec  t 
Other  reject 
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*  Passing  Action  Category 

*  Reply  Category 

Substitute  item  reject  reply 
FSCM/part  number  change  reject  reply 
Offer  accept  or  reject 

b.  Internal  Outputs.  There  are  five  types  of  internal 
outputs  required  under  the  system  redesign  concept  to  provide 
adequate  communications  of  system  actions  to  all  levels  of  users 

(1)  Skeleton  File  Maintenance  Transactions  should 
be  generated  by  both  SICCs  and  IMMs  when  manual  actions  are 
required  before  automated  processing  of  SSR  transactions  may 
continue.  The  type  of  skeleton  file  maintenance  transactions 
should  be  patterned  after  those  used  by  some  SICCs/IMMs  in  the 
current  system  and  are  described  in  the  processing  section 
above  . 


(2)  Functional  Listings  similar  to  some  of  those 
currently  produced  will  be  necessary  under  the  system  redesign 
to  allow  efficient  manual  processing  of  part  numbered  SSR  items, 
advice  transactions,  etc.  Some  of  these  listings  should  be  eli¬ 
minated  from  the  system  redesign  in  particular  those  which  con¬ 
stitute  manual  history  files. 

(3)  Inquiry  Replies  should  be  extensively  revised 
to  provide  a  total  audit  trail  of  actions  taken  on  an  item  basis 
This  allows  the  functional  user  to  adequately  determine  the 
reason  behind  advice  decisions  and  to  provide  more  complete 
responses  to  questions  raised  by  SICCs,  management  personnel  or 
systems  designer. 

(A)  Operational  Reports.  The  few  operational  re¬ 
ports  currently  produced  by  automated  systems  were  found  to  be 
informative  in  nature  rather  than  identifying  specific  problems 
or  requiring  corrective  action.  Operational  reports  keyed  to 
potential  problem  areas  need  to  be  included  in  the  system  rede¬ 
sign.  Some  examples  of  these  problem  oriented  operational 
reports  include: 


* 

multiple  rejects. 


' 'unts  of  the  number  of  items  receiving 


*  Counts  of  the  number  of  items  requiring 
generation  or  processing  of  passing  actions. 

*  Counts  of  the  number  of  items  for  which 
multiple  followups  are  sent  or  received. 

*  Counts  of  invalid  data  rejects  including  the 
number  of  invalid  data  elements  per  item. 


*  Counts  of  external  transactions  received/ 
Internal  transaction  generated  which  did  not  match  on  SSR  control 
number  to  the  SSR  suspense  file. 

(5)  Management  Reports  are  curently  not  generated 
by  Components.  These  type  of  reports  showing  cyclic  results  over 
a  long  period  of  time  should  be  developed  in  the  system  redesign. 
These  types  of  reports  should  enable  managers  to  pinpoint  problem 
areas  such  as  processing  bottlenecks  or  system  deficiencies/in¬ 
accuracies  . 

c.  Output  System  Considerations.  Output  system  con¬ 
siderations  are  basically  identical  to  those  discussed  for  inputs 
above.  It  is  appropriate  to  repeat  here  that  the  automated  sys¬ 
tems  should  be  executed  on  a  daily  basis  and  that  communications 
between  SICCs  and  IMMs  should  be  accoplished  using  AUTODIN  to 
the  greatest  extent  possible.  A  direct  tie-in  between  SICC/IMM 
computers  and  AUTODIN  terminals  is  again  the  preferred  transmis¬ 
sion  mode,  when  possible.  Where  this  direct  tie-in  does  not 
exist  an  automated  interface  using  disk  or  magnetic  tape  should 
be  used. 

7.  Controls .  This  section  is  divided  into  two  subsections 
to  discuss  improvements  to  controls  in  the  current  system  and 
those  required  in  the  system  redesign. 

a .  Current  System  Controls 

There  are  two  actions  which  require  revision  under 
the  current  system  to  make  it  operate  more  realistically. 

First,  the  current  practice  of  generating  followup  transactions 
by  SICCs  based  on  the  Date  of  Request  of  the  LISSR  transaction 
must  be  changed.  The  operational  review  and  the  data  analysis 
show  that  this  practice  is  causing  followup  transactions  to  be 
received  by  IMMs  before  the  allowed  25  days  have  elapsed.  This 
problem  is  caused  by  assignment  of  the  DOR  by  the  automated  SSR 
application  based  on  the  process  date.  There  is  a  certain 
amount  of  internal  processing  which  is  then  accomplished  prior 
to  mailing  the  LISSR  transactions  to  the  IMM.  When  the  DOR  is 
assigned  as  the  process  date,  this  SICC  internal  processing  time 
is  charged  against  the  25  days  IMM  processing  time  in  terms  of 
followup  transaction  generation.  The  SICCs  should  predicate 
generation  of  followup  transactions  based  on  the  date  the  LISSR 
transactions  are  actually  forwarded  to  the  IMM  for  processing. 

When  IMMs  receive  followup  transactions  which  cannot 
be  matched  to  a  LISSR  transaction  in  the  IMM  files,  a  followup 
response  transaction  is  generated  containing  an  advice  Indicat¬ 
ing  "no  record"  and  forwarded  to  the  SICC.  When  this  followup 
response  is  received  by  the  SICC,  a  resubmission  of  the  original 
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LISSR  transaction  is  generated  and  resubmitted  to  the  IMM.  This 
generation  may  be  done  on  an  automated  or  manual  basis,  but  is 
generally  done  immediately  upon  receipt  of  the  "no  record"  advice. 
The  data  analysis  shows  that  this  "no  record"  advice  is  given 
many  times  because  the  original  LISSR  transaction  had  not  yet 
been  received  by  the  IMM.  This  occurs  when  the  followup  trans¬ 
action  is  transmitted  via  AUTODIN,  while  the  LISSR  transactions 
are  mailed  to  IMMs.  This  situation  is  also  caused  by  the  rela¬ 
tionship  between  the  DOR  and  date  of  submittal  of  the  LISSR 
transactions  described  above.  To  reduce  the  number  of  the  need¬ 
less  resubmittals  of  LISSR  transactions  and  the  resulting  addi¬ 
tional  processing  required  by  both  SICCs  and  IMMs,  SICCs  should 
wait  at  least  15  days  before  generating  a  LISSR  resubmission 
when  "no  record"  advice  is  received  on  followup  response  trans- 
ac  tions  . 

b.  System  Redesign  Controls.  In  this  subsection  exter¬ 
nal  controls  are  discussed  first  followed  by  a  discussion  of 
internal  controls.  There  is  one  type  of  control  which  is  common 
to  both  and  therefore  will  be  discussed  first.  This  first  type 
serves  as  the  primary  control  over  SSR  item  processing  in  the 
system  redesign  and  is  the  SSR  control  number.  This  control 
number  was  discussed  in  the  inputs  section  above  and  should  be 
used  as  the  central  control  for  sequencing,  processing,  storing, 
retrieving,  and  validating  all  SSR  transactions  by  both  SICCs 
and  IMMs . 

( 1 )  External  Controls 

External  controls  generally  consist  of  followup 
transactions  and  response  transactions  to  these  followup  trans¬ 
actions.  Followup  transactions  are  generated  in  the  current 
system  when  the  SICC  has  not  received  initial  advice  or  an  NSN 
Notification  within  the  time  standards  established  by  the  IMM 
Manual.  The  SICC  has  no  way  of  communicating  to  the  IMM  whether 
he  is  following  up  for  initial  advice  or  final  advice  (NSN  Noti¬ 
fication)  in  the  current  system.  The  system  redesign  should 
provide  for  transaction  codes  to  allow  the  SICC  to  communicate 
to  the  IMM  that  the  followup  transaction  is  for  initial  advice 
or  for  final  advice  and  this  transaction  code  should  be  con¬ 
sidered  by  IMMs  in  providing  a  response  to  the  followup  transac¬ 
tion.  Followup  response  transactions  in  the  current  system  are 
'  a  separate  type  of  LIAC  even  though  the  format  Is  similar  to 

'  that  of  the  advice  transaction  and  the  response  is  processed  by 

SICCs  the  same  as  an  advice  transaction.  When  the  response  does 
not  contain  all  of  the  information  that  the  corresponding  advice 
transaction  contains,  the  SICC  cannot  complete  processing  of  the 
item.  The  results  of  the  validation  analysis  seem  to  indicate 
that  when  a  response  is  provided,  it  does  not  always  contain  the 
identical  information  as  the  original  advice  transaction,  par¬ 
ticularly  for  those  advice  transactions  requiring  entrance  of 
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data  other  that  the  ATC  only  (e.g.,  NSN).  In  the  system  rede¬ 
sign,  a  separate  transaction  type  should  not  exist  for  response 
transactions,  but  a  duplicate  of  the  original  advice  transaction 
should  be  generated  for  transmittal  to  the  SICC  as  a  response  to 
the  followup  transaction. 

There  are  two  additional  types  of  followup  trans¬ 
actions  required.  The  first  is  a  followup  for  an  offer  reply. 

In  the  current  system,  when  an  offer  reply  transaction  is  not  re¬ 
ceived  after  60  days  have  elapsed  since  the  date  of  offer  advice, 
the  I  MM  may  reject  the  LISSR  transaction.  The  study  team  has 
determined  that  it  would  be  preferable  to  provide  a  means  for 
the  IMM  to  followup  to  the  SICC  when  an  offer  reply  is  overdue. 
This  would  provide  a  better  and  more  timely  processing  flow 
leading  to  final  ac ce p t a nc e / r e j e c t i on  of  the  SSR  item  than  the 
current  system  provides.  An  offer  reply  from  the  SICC  would 
serve  as  a  response  to  this  type  of  followup  transaction. 

The  second  type  of  followup  also  concerns  a 
followup  by  the  IMM  to  the  SICC.  As  described  earlier,  some 
activities  have  designed  systems/procedures  to  fol lo wup  either 
internally  or  extsrnally  for  submission  of  technical  data  when  a 
Date  Technical  Data  to  be  Supplied  is  provided  in  the  Part  Number 
LISSR  transaction.  \  The  Study  Team  believes  that  this  procedure 
should  be  automatedX unde r  the  system  redesign  concept  and  that  a 
followup  transaction'^  be  provided  for  the  IMM  to  remind  the  SICC 
that  technical  data  should  be  submitted  for  these  items.  A 
response  transaction  \hould  also  be  provided  for  the  SICC  to 
indicate  that  the  technical  data  is  being  forwarded  or  that  it 
is  not  available.  *•  . 

\ 

It  is  important  to  note  that  all  of  these  fol¬ 
lowup  transactions  may  bt\  generated  by  automated  SSR  Systemd 
based  on  automated  suspenses.  Most  of  these  followups  may  be 
processed  partially  or  totally  on  an  automated  basis  also  unlder 
the  total  concept  of  syste\  redesign.  j 

(2)  Internal  c\n  t  r  o 1 s  .  Internal  controls  consist 
of  functional  notifications  \o  advise  that  immediate  manual 
action  is  required.  AlthoughN  these  functional  notifications 
should  be  generated  on  a  SlCC'^and  an  IMM  basis,  the  conditions 
under  which  these  no  1 1  f  i  c  a  t  i onV?  should  be  generated  differ; 
therefore,  SICC  functional  no  f  i,t  i  ca  t  ions  are  discussed  separately 
from  IMM  functional  notifications.  The  specific  notifications 
discussed  here  are  meant  to  be  Examples  of  the  types  of  con¬ 
ditions  which  should  key  generation  of  functional  notifications 
and  are  not  all  inclusive. 

(a)  SICC  Functional  Notifications.  Functional 
notifications  should  be  output  whep  an  advice  transaction  is 
received  which  requires  a  reply  such  as  offer  advice  and  when 
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reject  advice  Is  received  to  begin  resubmittal  action.  These 
type  of  functional  notifications  provide  an  excellent  opportunity 
to  use  skeleton  file  maintenance  transactions  for  updating  auto¬ 
mated  SSR  files  and  generating  the  proper  reply  or  resubmission 
transactions.  These  notifications  should  be  output  again  when 
established  timeframes  for  completing  these  actions  are  not  met, 
or  in  the  case  of  offer  advice  transactions,  when  an  offer  reply 
followup  transaction  is  received  from  the  IMM.  A  functional 
notification  should  also  be  output  for  processing  when  technical 
data  followup  transactions  are  received  from  IMMs.  Other  func¬ 
tional  notifications  should  be  part  of  the  system  redesign  based 
on  time  standards  and  goals  established  in  the  SSR  procedures. 

(b)  IMM  Functional  Notifications.  Currently, 
functional  notifications  are  output  within  DLA  to  indicate  items 
which  are  close  to  the  time  standard  established  in  the  IMM 
Manual  and  the  items  for  which  advice  is  overdue.  These  func¬ 
tional  notifications  are  output  each  cycle  and  do  not  seem  to 
key  specific  manual  actions.  The  system  redesign  should  provide 
functional  notifications  when  exception  processing  is  required. 
When  a  followup  for  initial  or  final  advice  is  received  by  an 
IMM  and  the  required  advice  does  not  reside  in  the  automated  SSR 
files,  a  functional  notification  relating  this  information 
should  be  output  for  immediate  manual  processing  functional 
notifications  should  also  be  output  when  advice  is  overdue  to 
the  SICC  whether  or  not  of  a  followup  is  received.  Functional 
notifications  should  also  be  produced  when  responses  to  tech¬ 
nical  data  followup  transactions  are  received  by  the  IMM.  Other 
types  of  exceptional  conditions  which  should  key  functional 
notifications  so  that  manual  processing  is  taken  include: 

-  Multiple  followup  transactions  sent  to  a 
SICC  for  the  same  item. 


-  Multiple  followup  transactions  received 
from  a  SICC  for  the  same  item. 

-  Multiple  reject  advice  transactions 
generated  to  a  SICC  for  the  same  item. 
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PART  2  -  MANAGEMENT,  POLICIES  AND  PROCEDURES 


A.  INTRODUCTION 

The  DODSSR  Study  was  assigned  to  identify  problems  associated 
with  the  systems  for  generating,  transmitting,  processing  and 
controlling  SSRs  in  order  to  develop  systems  and  procedures  im¬ 
provements  to  promote  effective  and  efficient  supply  support  of 
DoD  equipments.  The  systems  approach  was  used  to  review  the 
management  environment  consisting  of  the  policies,  procedures, 
organizations,  functions  and  systems  necessary  to  accomplish  SSR 
processing.  A  'top  down  approach*  was  used  by  first  looking  at 
the  management  organizations  and  their  respective  functions  or 
responsibilities  involved  in  the  definition  of  requirements,  and 
the  subsequent  design  and  implementation  of  systems  to  accomplish 
the  functional  requirements.  The  specific  methodology  included 
the  use  of  systems  analysis,  performance  evaluation  and  problem 
Identification  and  analysis  to  develop  and  recommend  improvements 
in  SSR  management,  policies,  systems  and  procedures.  The  compar¬ 
ative  analysis  of  systems  design  and  operational  implementation 
i 8  contained  in  Part  1  of  this  Chapter.  This  part  contains  the 
analysis  and  conclusions  associated  with  management  organizations/ 
functions  and  policy  and  procedures. 

B.  MANAGEMENT  REVIEW 

1 .  Organizational /Functional  Assignment 

The  supply  support  request  function  Interfaces  with  pro¬ 
visioning,  inventory  control,  technical,  procurement  and  catalog¬ 
ing  functions.  The  functional  responsibility  for  development  of 
policy,  determination  of  functional  requirements,  and  design, 
development  and  implementation  of  systems  varied  significantly 
at  the  headquarters,  systems  design  and  operational  levels.  This 
was  first  noticed  in  the  assignment  of  contact  points  for  the 
DODSSR  Study.  The  study  assignment  requested  that  members  of  the 
Special  Projects  Group  (SPG)  for  provisioning  be  assigned  as  con¬ 
tact  points  for  the  study,  because  it  was  felt  that  this  group 
would  be  the  most  knowledgeable  in  the  entire  process  for  gener¬ 
ating,  transmitting,  pror  .  ng  and  controlling  supply  support 
requests  . 


The  SPG  repre^^otatives  were  assigned  as  headquarters 
level  contact  points  by  the  Army,  Navy,  Air  Force,  Marine  Corps 
Defense  Logistics  Agency  (DLA),  and  General  Services  Administra¬ 
tion  ( GSA) .  But  as  a  matter  of  practice,  additional  operational 
contact  points  for  the  headquarters  level  were  assigned  by  two 
of  the  Components.  When  the  study  team  attended  meetings  of  the 
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SPG  to  participate  in  the  discussion  of  problems  or  to  provide 
status  briefings,  often  the  secondary  contact  points  were  not 
informed  and  did  not  attend  the  meetings  of  the  SPG  at  which  SSR 
matters  were  being  discussed.  In  reviewing  the  functional  areas 
that  spawned  our  headquarters  level  contact  points  we  noticed 
several  distinct  functional  orientations.  Some  of  the  contact 
points  had  a  provisioning  orientation,  while  others  had  an  inte¬ 
grated  materiel  management  assignment  and  others  had  a  cataloging 
or  inventory  control  background.  Although  the  SSR  process  is 
involved  with  all  these  functions,  some  of  the  contact  points 
did  not  appear  to  possess  a  working  knowledge  of  processes  other 
than  that  of  their  immediate  assignment,  and  matters  pertaining 
to  different  functional  areas  did  not  appear  to  be  well  coordi¬ 
nated  with  the  applicable  functional  elements  when  there  was  a 
split  assignment  of  responsibility. 

The  functional  requirements  that  are  developed  by  the 
headquarters  level  influence  the  design,  development  and  imple¬ 
mentation  of  systems  to  implement  the  functional  requirements. 

The  degree  of  integration,  interface  or  compatibility  of  auto¬ 
mated  SSR  subsystems  varied  among  SICCs  and  IMMs  and  to  some 
extent  reflected  the  split  functional  assignments  at  the  head¬ 
quarters  level.  In  one  case  the  automated  provisioning  subsystem 
was  designed  by  one  activity  and  the  SSR  subsystem  was  designed 
by  another.  In  one  case  a  separate  subsystem  was  designed  for 
incoming  and  outgoing  SSRs.  Two  of  the  Components  used  program 
routines  from  the  requirements  subsystem  to  compute  requirements 
while  others  built  separate  computational  routines  into  their 
provisioning  or  SSR  subsystems.  The  design  of  SSR  subsystems  in 
some  cases  appeared  to  be  influenced  by  the  fact  that  subsystems 
for  other  functional  areas  had  already  been  developed  and  the 
SSR  application  was  designed  as  an  "add-on"  application  to  inter¬ 
face  with  existing  applications.  In  addition  it  was  noticed 
that  the  design  control  of  the  systems  design,  and  the  opera¬ 
tional  control  of  the  systems  design  organizations  and/or  the 
operational  organizations  sometimes  come  under  the  command  con¬ 
trol  of  different  organizational  elements  at  the  Component  head¬ 
quarters  level. 

Responsibilities  for  generating,  transmitting,  pro¬ 
cessing,  controlling  and  managing  supply  support  requests  also 
varied  organizationally  and  functionally  at  both  SSR  submitting 
(SICC)  and  receiving  (IMM)  operational  activities.  Performance 
of  the  functions  of  selecting  candidate  requests,  determining 
quantitative  requirements,  performing  item  identification, 
making  method  of  support / level  of  support  and  advice  decisions, 
screening  catalog  files,  accomplishing  item  entry  control,  and 
performance  of  cataloging  actions  varied  organizationally  and 
functionally.  Provisioning,  technical,  cataloging  and  inventory 
control  organizations  performed  various  tasks  at  submitting 
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activities.  Inventory  control,  technical  and  cataloging  organi¬ 
zations  performed  various  tasks  at  the  I  MM  receiving  activities. 
The  principal  tasks  at  SICC  submitting  activities  involve  selec¬ 
tion  of  maintenance  significant  items,  determining  method  of 
management,  method  of  support  and  level  of  support,  and  perform¬ 
ing  item  id en t i f i c a t i on / i t em  entry  control  functions.  At  the 
IMM  receiving  activities  the  principal  tasks  include  method  of 
s u p por t / le ve 1  of  support  decisions  and  item  id en t i f i c a t i on  /  i t e m 
entry  control  functions.  It  would  seem  most  logical  that  the 
taks  of  generating,  submitting,  processing  and  controlling  SSRs 
should  be  performed  by  the  organizational  entities  having  the 
predominant  functions  involved  in  the  decision  making  processes 
involved  in  determining  support  requirements  at  the  requesting 
activity  and  the  responsibility  for  satisfaction  of  the  require¬ 
ment  at  the  managing  activity. 

In  view  of  the  varied  assignment  of  responsibilities  for 
functional  tasks  related  to  the  design,  development  and  imple¬ 
mentation  of  systems  to  accomplish  the  supply  support  request 
process,  the  Components  should  review  in  detail  the  management 
environment  described  in  Chapter  II,  Volume  I,  and  Volume  II  for 
each  of  the  Components.  This  should  permit  a  better  understand¬ 
ing  of  the  processes  involved  in  requesting,  obtaining  and  pro¬ 
viding  supply  support  and  enable  each  Component  to  individually 
determine  any  organizational,  functional  or  system  changes 
required  at  headquarters,  system  design  or  operational  activities 
to  improve  SSR  processing. 

2 .  Contractor  and  Provisioning  Processing 

The  standard  procedures  for  provisioning  contained  in 
MIL-STD-1561  (Appendix  D,  Reference  23)  and  preparation  of  pro¬ 
visioning  documentation  contained  in  MIL-STD-1552  (Appendix  D, 
Reference  22)  delineate  the  responsibilities  of  Components  in 
the  Department  of  Defense  and  of  contractors  in  provisioning  end 
items  of  equipment.  The  quantitative  evaluation  in  Volume  III 
indicated  that  most  of  the  SSRs  are  generated  as  a  result  of  the 
provisioning  process.  By  the  same  token,  most  of  the  data  con¬ 
tained  in  SSRs  is  obtained  from  the  provisioning  technical  docu¬ 
mentation  produced  by  the  contractor  in  accordance  with  the 
Provisioning  Requirements  Statement  and  Contractor  Data  Require¬ 
ments  List  as  specified  in  the  end  item  contract.  Supply  Support 
Request  control  and  transaction  identification  data  are  generally 
introduced  by  the  SSR  subsystem,  although  some  control  data  such 
as  item  serial  number  is  sometimes  obtained  from  the  provisioning 
documentation. 

If  data  required  in  the  SSR  is  not  specified  as  required 
in  the  provisioning  technical  documentation,  it  will  not  be 
available  for  entry  into  the  SSR.  If  the  contractor  does  not 
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correctly  enter  required  data  into  the  provisioning  list,  it 
will  be  incorrectly  entered  into  the  SSR  unless  validated  during 
provisioning  processing  by  the  provisioning  activity  and  rejected 
for  correction  by  the  contractor  prior  to  entry  into  provisioning 
files  by  the  provisioning  activity.  Analysis  of  our  field  re¬ 
search  and  quantitative  evaluation  indicates  that  a  number  of 
errors  are  occurring  due  to  a  combination  of  data  not  being  pro¬ 
vided  in  the  provisioning  documentation,  data  being  incorrectly 
entered  in  the  provisioning  documentation  by  the  contractor  and 
not  properly  validated  and  corrected  during  provisioning  pro¬ 
cessing. 

The  time  to  ensure  that  data  required  for  SSRs  is  avail¬ 
able  in  a  correct  form  is  during  the  provisioning  process.  By 
the  time  an  SSR  is  prepared,  forwarded  to  an  IMM,  validated  by 
the  IMM,  and  rejected  back  to  the  SICC,  it  may  be  too  late  to 
obtain  the  correct  data  from  the  contractor.  In  any  event,  it 
is  much  more  difficult  and  time  consuming  to  attempt  to  correct 
errors  after  they  have  been  submitted  to  the  IMM  and  rejected 
than  to  correct  them  during  provisioning  processing.  It  may  be 
difficult  to  trace  the  audit  trail  for  a  line  i  t  e  p  that  has  been 
rejected  by  an  IMM  during  SSR  processing  back  to  the  SICC  SSR 
suspense  files,  then  to  the  provisioning  files  and  back  to  the 
original  provisioning  list  to  obtain  clarification  from  the  con¬ 
tractor.  The  provisioning  list  may  already  have  been  accepted 
by  the  provisioning  activity  and  it  may  be  difficult  or  time 
consuming  to  obtain  the  information  from  the  contractor.  If  the 
PCC  and  ISN  in  the  SSR  do  not  directly  relate  to  the  PCCN  and 
PLISN  of  the  provisioning  list,  it  may  be  impossible  to  obtain 
the  information  required  to  correct  the  SSR. 

The  Components  should  review  their  provisioning  pro¬ 
cessing  operations  to  ensure  that  data  required  for  entry  into 
SSRs  is  specified  in  the  contract  data  requirements  and  the  pro¬ 
visioning  documentation  should  be  validated  to  ensure  that  the 
data  is  correctly  entered  prior  to  accepting  the  provisioning 
documentation.  Resubmission  of  the  provisioning  documentation 
or  clarification  of  individual  items  should  be  obtained  prior  to 
entry  of  data  for  individual  provisioning  line  items  into  provi¬ 
sioning  files.  Particular  attention  should  be  given  to  the 
following  data. 

Technical  Data ■  The  lack  of  technical  data  or  inade¬ 
quate  technical  data  was  one  of  the  most  persistent  problems 
reported  during  field  research.  About  40%  of  the  part  numbered 
SSRs  are  sent  to  the  IMM  without  technical  data.  Some  of  the 
technical  data  that  is  received  does  not  contain  the  minimum 
data  required  for  stock  number  assignment. 

FSCM/ Re f e r e nc e  Number.  The  quantitative  evaluation 
indicated  that  there  are  a  large  number  of  rejects  attributable 
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Co  manufacturer's  codes  and  reference  numbers  that  have  been 
incorrectly  entered  or  formatted.  These  are  some  of  the  most 
important  data  elements  and  should  be  reviewed  carefully.  Con¬ 
sideration  should  be  given  by  the  Defense  Logistics  Services 
Center  to  prepare  a  training  course  in  formatting  and  entering 
manufacturer's  part  numbers  and  codes.  Training  seminars  should 
be  given  to  contractors  and  provisioning  activities. 

Unit  of  Issue.  If  the  unit  of  issue  is  incorrect  it 
cannot  always  be  corrected  by  the  IMM.  This  is  a  key  element 
and  must  be  meaningful  and  relatable  to  the  requested  retail  and 
replenishment  quantities. 

Item  Names.  An  approved  item  name  is  needed  to  enable 
stock  number  assignment  for  an  item.  This  is  another  element 
for  which  training  should  be  provided  by  DLSC  to  contractors  and 
provisioning  activities. 

-  PL  I S  N .  The  provisioning  line  item  sequence  number 
should  be  entered  in  accordance  with  the  standard.  The  quan¬ 
titative  evaluation  showed  that  the  provisions  of  the  military 
standard  were  not  being  adhered  to  by  provisioning  contractors 
and  activities.  The  fifth  position  of  the  PLISN  was  not  always 
being  used  to  indicate  adds  and  the  sixth  position  to  indicat” 
deletions  and  modifications.  The  entire  six  positions  were 
being  used  in  some  instances  to  reflect  a  basic  six-position 
number  instead  of  a  basic  f o ur - po s i t i on  number  with  the  fifth 
and  sixth  digits  used  to  reflect  adds,  deletions  and  modifica¬ 
tions.  The  PLISN  should  be  unique  to  a  PCC  to  prevent  dupli¬ 
cates  and  to  permit  the  maintenance  of  an  audit  trail. 

PCC .  A  separate  PCC  should  be  assigned  to  each  pro¬ 
visioning  list.  The  quantitative  evaluation  indicated  that 
sometimes  the  same  PCC  was  being  assigned  to  an  entire  weapons 
system.  When  individual  provisioning  lists  were  received  from 
the  contractor  for  individual  pieces  of  equipment  on  the  weapon 
system,  the  same  PLISN  was  being  used  for  the  same  or  different 
items  of  supply  causing  actual  or  apparent  duplicates  ir.  SSRs 
that  were  sent  out  on  the  same  or  different  days.  If  these  SSRs 
are  received  and  processed  during  the  same  cycle  by  the  IMM, 
they  can  be  treated  as  duplicates  or  advice  sent  out  on  one  item 
may  be  incorrectly  recorded  by  the  SICC  on  the  wrong  item. 

-  Unit  Price.  The  unit  price  is  an  item  that  should  be 
available  on  every  provisioning  list  and  is  a  key  element  needed 
in  processing  of  an  SSR. 

Production  Leadtime.  This  data  element  is  needed  to  - 
compute  support  dates  for  new  items  of  supply  and  is  needed  to 
compute  levels  of  support  until  an  actual  production  leadtime 
can  be  established  for  new  items. 
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3.  Provisioning  Screening.  The  quantitative  evaluation 
indicated  that  there  were  a  large  number  of  rejects  due  to  FSC/ 
Manager  and  NSN/PSCN  errors.  These  are  items  for  which  the  I  MM 
screened  DLSC  and  obtained  information  that  the  SI CC  had  for¬ 
warded  the  item  to  the  incorrect  manager,  had  placed  the  item  in 
the  wrong  FSC,  or  had  not  picked  up  NSN  assignments  for  part 
numbers  or  the  latest  s t and a r d i z a t i on / r e p lac e men t  actions  on 
record  in  DLSC.  This  is  another  area  where  DLSC  should  consider 
a  training  program  for  contractors  and  provisioning  activities 
to  promote  more  effective,  efficient  and  timely  provisioning 
screening.  Cons i de ra t i on  should  also  be  given  to  automation  of 
processing  of  the  results  provided  by  DLSC  using  the  standardiza¬ 
tion  codes,  match  codes  and  other  information  that  could  be  used 
to  make  an  automated  decision.  This  would  reduce  the  number  of 
actions  left  over  for  manual  review. 

4 .  Pr o v 1 s lo n 1 ng / Supp 1 y  Support  Schedules 

Current  provisioning  procedures  provide  for  the  provi¬ 
sioning  activity  to  develop  a  provisioning  performance  schedule 
to  coordinate  the  receipt  and  processing  of  provisioning  docu¬ 
mentation  in  order  to  select,  procure  and  obtain  repair  parts  to 
support  end  items  by  the  end  item  delivery  dates.  Th» 
repair  parts  are  required  and  the  date  stock  numbers  are  required 
that  are  included  in  SSRs  are  related  to  the  end  item  delivery 
dates  and  the  provisioning  schedules.  The  production  leadtime 
for  the  repair  parts  is  included  in  the  line  item  SSRs  to  permit 
the  IMM  to  schedule  the  supply  support  request  process  to  ensure 
repair  parts  are  in  the  I  MM  '  s  wholesale  distribution  system  in 
time  to  meet  the  date  repair  parts  are  required. 

If  the  IMM  cannot  meet  the  requested  date  for  a  new  item, 
the  IMM  may  provide  a  new  support  date  to  the  SICC.  The  quanti¬ 
tative  analysis  indicated  that  the  DRPRs  being  provided  by  the 
SICCs  were  not  realistic  in  terms  of  the  production  leadtime  of 
the  items  being  requested.  The  IMM  is  allotted  60  days  from  the 
date  of  receipt  of  the  SSR  to  perform  its  actions  and  provide  an 
NSN  to  the  SICC.  The  combination  of  late  submission  of  SSRs  by 
the  SICCs  In  terms  of  the  unrealistic  date  repair  parts  required 
and  production  leadtimes  provided  by  the  SICCs  are  a  major  factor 
in  the  large  number  of  new  support  dates  being  provided  by  the 
IMMs  and  the  failure  to  provide  materiel  and  NSNs  by  the  dates 
requested  by  the  SICCs. 

The  Components  should  review  their  provisioning  perfor¬ 
mance  schedules  to  ensure  the  timely  receipt  of  quality  provision¬ 
ing  technical  data  from  contractors  in  terms  of  the  end  item 
delivery  datts  and  repair  parts  production  leadtimes,  and  to 
require  the  identification  of  IMM  items  and  preparation  and  sub¬ 
mission  of  SSRs  sufficiently  in  advance  of  the  production  lead- 
time  and  the  date  repair  parts  are  required  in  order  to  allow 
enough  Lime  for  the  accomplishment  of  IMM  actions. 


_  1 

specify  timeframes  for  completing  events,  there  is  no  performance  ; 

evaluation  system  to  measure  the  performance  of  the  SSR  system.  ; 

The  IMM  Manual  does  not  establish  any  performance  goals  or  objec¬ 
tives  and  does  not  provide  for  measurement  criteria  or  a  reporting 
system  to  measure  performance  against  pre-established  goals  and 
report  system  accomplishments.  Effectiveness  and  efficiency 
objectives  and  measurement  criteria  should  then  be  established 
for  critical  events  and  a  performance  evaluation  system  estab¬ 
lished  to  measure  the  performance  of  the  system.  Acc e p t / re j ec t 
rates  should  be  established  for  each  of  the  transaction  categories 
and  on  time  completion  rates  established  for  critical  events. 

The  performance  objectives  and  completion  rates  should  be  incor¬ 
porated  into  the  work  measurement  and  performance  evaluation 
systems  of  the  SICC  and  IMM  activities.  Performance  evaluation 
reports  should  be  accumulated  by  activity  over  time  and  forwarded 
to  the  System  Administrator  for  evaluation. 

a.  Allowed  Times  .  The  current  timeframes  in  the  IMM 
Manual  should  be  revised  to  provide  for  more  realistic  times 
based  upon  the  use  of  AUTODIN,  elimination  of  the  package  con¬ 
cept  for  processing  and  use  of  automated  processing  and  direct 
communication  from  data  processing  to  AUTODIN  processing,  re¬ 
stricting  manual  processing  to  the  minimum.  A  transaction  date 
should  be  placed  in  each  transaction  which  should  be  used  as  the 
basic  starting  point  in  measuring  times  for  individual  transac¬ 
tions  and  total  supply  support  request  life  cycle  time.  The 
date  of  transaction  should  be  the  date  the  transaction  was 
created  and  forwarded  to  AUTODIN  for  transmission.  Recommended 
times  are  shown  below: 

:  AUTODIN  Transmission  -  Five  days  from  date  of  transmission 

to  date  of  receipt  . 

:  Initial  Advice  -  Provide  initial  ac c e p t / re j ec t  advice 

for  an  NSN/PSCN  request  within  15 
days  from  date  of  the  request  trans¬ 
action  . 

-  Provide  initial  accept /re ject  advice 
for  a  part  number  item  within  30 
days  from  the  date  of  the  request 
transaction. 

:  Flnal/NSN  Advice  -  Provide  within  60  days  of  the  date 

of  the  request  transaction  or  30 
days  after  initial  advice,  which¬ 
ever  is  sooner. 

:  Offer  -  Provide  an  offer  within  30  days  of 

the  date  of  the  request  transaction. 
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Replies 


Followups 


Responses 


Resubmission  of 
Rejects 


-  Reply  to  conditional  accept  and 
offer  transactions  within  30  days 

of  the  accept/offer  transaction  date. 

-  All  initial  followups  should  be 
generated  no  earlier  than  five  days 
after  the  expiration  of  the  allowed 
time  for  completion  of  the  transac¬ 
tion  for  which  the  followup  is  being 
sent.  Subsequent  followups  should 
be  generated  five  days  after  the  al¬ 
lowed  time  for  the  expected  response. 

-  All  responses  to  any  followup  will 
be  made  within  15  days  of  the  date 
of  the  followup  transaction.  If  a 
proper  response  cannot  be  provided 
within  15  days,  an  interim  response 
may  be  provided  indicating  that  the 
action  is  in  process  and  that  advice 
will  be  provided  in  15  days  from  the 
date  of  the  reponse  transaction. 

-  All  requests  that  have  been  rejected 
and  require  correction  and/or  resub¬ 
mission  will  be  resubmitted  within 
30  days  of  the  date  of  the  reject. 


Request  Cancellation  -  All  SSR  cancellations  must  be  sub¬ 
mitted  within  15  days  of  the  date 
of  receipt  of  an  advice  transaction 
containing  an  unacceptable  support 
date  . 


Technical  Data 
Submission 


NS N  Assignment 


Provisioning 

Screening 

SSR  Generation 


-  Technical  data  which  is  available 
should  be  provided  within  30  days 
of  the  transaction  date  of  the 
request . 

-  Seven  days  from  date  of  transaction 
request  for  NSN  assignment  until 
accept  of  NSN. 

-  Seven  days  from  date  of  screening 
transaction  until  receipt  of  results. 

-  Submit  supply  support  requests  within 
30  days  after  SM&R,  IMC  and  require¬ 
ments  determinations  have  been  com¬ 
pleted  on  IMM  items. 
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b.  Goals .  Goals  should  be  established  to  measure  the 
effectiveness  and  efficiency  of  the  SSR  system*  Performance 
objectives  should  be  established  for  the  measurement  of  the  com¬ 
pletion  of  critical  events  and  to  measure  accept /re ject  rates 
and  the  submission  of  technical  data. 


( 1 )  Reject  Rates 

NSN/PSCN  Requests  -  10%  overall  reject  rate. 

-  5%  validation  reject  rate. 

Part  Number  Requests  -  20%  overall  reject  rate. 

-  10%  validation  reject  rate. 


( 2 )  Technical  Data  Rate 


Technical  Data  Rate  -  75%  supplementary  technical 

data  submitted  for  part  number 
items. 


( 3 )  Completion  Times 
AUTODIN  Transmission 
Initial  Advice 
Final/NSN  Advice 
Replies 
Responses 
Re  subrals  s ions 
Technical  Data 
NSN  Assigned 
Provisioning  Screening 


99% 

within 

allowed 

time 

90% 

within 

allowed 

time 

90% 

within 

allowed 

time 

90% 

within 

allowed 

time 

95% 

within 

allowed 

time 

90% 

within 

allowed 

time 

90% 

within 

allowed 

time 

95% 

within 

allowed 

ti  me 

95% 

within 

allowed 

time 

c .  Management  Reports 

Both  SICCs  and  IMMs  should  develop  a  performance 
system  to  measure  the  effectiveness  and  efficiency  of  the  SSR 
system.  Management  reports  should  be  developed  to  measure  the 
accept / re jec t  and  technical  data  rates.  Event  completion  times 
should  be  measured  to  determine  the  time  to  accomplish  different 
Individual  events  and  total  life  cycle  time.  Reject,  technical 
data  submission  rates  and  event  completion  times  should  then  be 
compared  with  performance  objectives  to  establish  relative  system 
performance . 
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The  quantitative  evaluation  and  ed it /val idat ion  anal¬ 
ysis  provide  examples  of  the  type  of  reports  that  could  be  devel¬ 
oped.  Examples  of  the  types  of  reports  that  should  be  generated 
include: 


( 1 )  Reject  Rates 


Reject  rates  should  be  measured  by  reject  sub¬ 
category  and  total  for  all  rejects  by  SI CC  and  IMM.  The  report 
should  be  accumulated  on  a  monthly  or  quarterly  basis  and  the 
rates  per  reporting  period  projected  to  show  any  trends  that  may 
a  ppea  r . 


Reject  rates  should  be  developed  for  individual 
reject  code  and  ranked  in  order  cf  frequency  from  high  to  low. 
Rankings  should  be  available  by  activity  as  well  as  totals.  The 
high  reject  rate  items  should  be  reviewed  to  determine  the  cause 
of  the  reject  rate;  system,  procedures  or  activity  and  a  proposed 
change  developed  to  correct  the  problem.  The  "Other”  category 
should  be  continually  reviewed  to  determine  the  reasons  for  its 
usage  and  whether  there  is  an  existing  code  to  cover  the  condi¬ 
tion.  If  there  is  a  high  frequency  of  occurrence  of  a  condition 
for  which  there  is  no  definitive  code,  a  new  code  to  cover  the 
situation  should  be  considered. 

(2)  Technical  Data  Rates.  The  report  should  show 
information  pertaining  to  the  incidence  of  items  where  technical 
data  was  required,  available  and  received.  The  frequency  of 
followups  and  responses  to  followups  should  also  be  measured. 

The  report  should  show  activity  and  system  totals. 

(3)  Followups/Responses.  Statistics  should  be 
generated  on  the  number  of  followups  and  responses  by  followup/ 
response  category.  Counts  should  be  shown  by  activity  and 
system  total.  The  number  of  followups  per  request  should  be 
monitored  to  determine  if  the  system  is  being  responsive  or  if 
there  is  a  communications  problem. 

(4)  Rejects/Resubmissions  .  Statistics  similar  to 
that  for  f o 1 lo wups / re s p on s e s  should  be  developed. 

(5)  Processing  Time  Statistics.  Reports  should  be 
produced  to  measure  the  time  to  accomplish  events  in  accordance 
with  the  allowed  processing  time.  These  reports  should  show  the 
number  and  percent  accomplished  within  thd  standard,  the  average 
time,  the  median  time  (50%)  and  the  90%-ILE  as  a  minimum. 


(6)  Summary .  The  types  of  reports  shown  above 
should  be  generated  to  monitor  and  measure  the  performance  of 


the  system.  The  measurements  should  be  compared  with  pre-estab¬ 
lished  goals  to  determine  relative  system  performance.  The  use 
of  the  reports  over  time  can  be  used  to  detect  significant  trends 
or  problems  and  action  taken  to  determine  If  operational  methods, 
procedures,  or  systems  need  to  be  corrected  on  an  activity  or 
system  basis.  The  reports  can  also  be  used  to  generate  proposed 
changes  to  policies  and  procedures  contained  in  the  IMM  Manual. 

6.  Technical  Data  Transmission 


The  AUTODIN/TELEFAX  Test  indicated  the  potential  benefits 
to  be  gained  from  decreasing  the  time  to  transmit  technical  data 
while  at  the  same  time  increasing  the  control  over  the  process. 
Although  the  specific  facsimile  transmission  system  tested  was 
not  adequate  for  this  purpose,  it  did  show  that  the  concept  has 
merit  if  a  more  suitable  system  can  be  developed. 

A  study  should  be  assigned  to  the  Defense  Logistics  Anal¬ 
ysis  Office  to  perform  further  research  and  determine  the  feasi¬ 
bility  of  scanning  technical  data  at  one  geographic  location, 
converting  the  graphic  data  to  an  electrical  or  electronic  signal 
and  transmitting  the  signal  to  another  geographic  location  to  be 
converted  to  an  image  or  facsimile  of  the  input  document  of  suf¬ 
ficient  quality  to  be  used  for  technical  operations  functions 
and  retention  in  a  technical  data  library  repository. 

C .  POLICY 

1 •  Supply  Support  Methods 

The  quantitative  evaluation  pointed  out  that  there  were 
a  number  of  methods  currently  in  use  to  obtain  supply  support. 
Item  Management  Coding  (IMC)  transactions  are  being  used  to 
adopt  an  item  that  is  already  being  managed  by  an  IMM.  An  IMC 
can  be  used  whenever  there  Is  an  existing  NSN  on  an  item.  Under 
the  current  system  the  IMC  transaction  will  accomplish  the  up¬ 
dating  of  DLSC  records  to  record  the  IMC  and  to  record  user 
interest.  The  estimated  demand  data  in  the  IMC  Is  not  used  to 
perform  method  of  support/ level  of  support  decisions. 

The  add  user  transactions,  document  identifier  code  LAU, 
that  were  previously  forwarded  by  the  SICC  to  the  IMM  are  no 
longer  used  with  the  advent  of  the  new  SSR  Procedures.  The  add 
user  transaction  is  forwarded  to  DLSC  by  the  IMM  based  upon  the 
IMC  or  SSR  transaction. 

Special  Program  Requirements  (SPR)  transactions  should 
not  be  used  in  lieu  of  an  SSR.  The  SSR  is  intended  to  accom¬ 
modate  recurring  requirements,  while  the  SPR  is  intended  to 
accommodate  nonrecurring  requirements.  The  study  team  concluded 
that  the  SPR  was  sometimes  being  used  to  make  up  for  the  failure 
to  use  SSRs  properly,  particularly  in  forecasting  requirements 
for  follow-on  procurements.  This  is  discussed  more  fully  below. 
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The  NIMSR  transaction  is  used  for  nonconsumable  support 
requests.  The  volume  of  transactions  is  so  small  that  the  manual 
system  currently  being  used  appears  to  be  adequate.  The  informa¬ 
tion  in  the  NIMSR  is  similar  to  the  old  nonprovisioning  supply 
support  requests.  Since  these  manual  transactions  are  similar, 
and  processed  in  a  similar  fashion,  it  is  recommended  that  any 
attempts  to  automate  the  NIMSR  should  be  done  with  a  view  towards 
integrating  the  NIMSR  system  with  the  SSR  system  for  consumable 
items  as  the  old  manual  nonprovisioning  SSRs  were  included  in  the 
automated  consumable  SSR  system. 

The  study  group  concludes  that  all  requests  for  supply 
support  for  consumable  items  should  be  made  using  the  SSR  trans¬ 
actions  in  accordance  with  the  IMM  Manual,  whenever  there  is  any 
predictable  recurring  requirement.  If  the  expected  demand  is 
sporadic  in  nature  or  there  is  no  predicted  demand,  the  IMC  trans¬ 
action  could  be  used  if  the  SICC  desires  only  to  accomplish  the 
cataloging  actions  of  recording  the  IMC  and  the  user  interest  of 
the  SICC  Component.  If  there  is  predictable  demand  or  if  the 
requirement  is  generated  from  the  provisioning  process,  the  SSR 
should  be  used  to  permit  consideration  of  the  forecasted  demand. 
The  IMC  should  be  used  only  if  the  requirement  is  generated  out¬ 
side  the  provisioning  process  and  if  the  adopting  activity  desires 
cataloging  action  only  and  is  willing  to  rely  on  the  demand  fore¬ 
casting  process  that  considers  demands  based  upon  requisitions. 

2.  Supply  Support  Request  Usage.  The  SSR  Procedures  define 
an  SSR  as  "A  request  submitted  by  a  SICC  to  the  CIMM  or  WIMM 
which  manages  or  is  the  potential  manager,  of  the  item  or 
materiel  required.  For  items  requiring  Item  Management  Coding, 
the  SSR  is  used  as  an  IMC  card.”  The  IMM  Manual  does  not  list  a 
specific  purpose,  objective  or  intent  for  SSRs.  Chapter  I  of 
the  IMM  Manual  provides  general  guidance  applicable  to  Item 
Management  Coding,  Logistic  Reassignment  and  Supply  Support 
Requests.  The  stated  purpose  or  objective  is  to  eliminate  the 
duplication  of  effort  in  the  wholesale  materiel  management  of 
consumable  items  through  the  application  of  approved  IMC  criteria 
and  the  utilization  of  uniform  procedures.  The  only  specific 
purpose  or  objective  for  SSRs  is  a  reference  to  IMMs  to  provide 
timely  support.  Accordingly,  it  Is  felt  that  the  policy  section 
of  the  IMM  Manual  containing  the  SSR  procedures  should  be  revised 
to  include  a  more  appropriate  definition  and  purpose  of  supply 
support  requests  to  reflect  the  intent  of  integrated  materiel 
management . 

a.  Proposed  SSR  Definition.  A  supply  support  request 
is  a  request  submitted  by  a  SICC  to  an  IMM  to  obtain  Integrated 
Materiel  Management  support  for  new  or  existing  consumable  items 
of  supply.  Integrated  Materiel  Management  is  defined  in  DoDD 
4140.26  (Appendix  D,  Reference  16)  as  the  exercise  of  total  De¬ 
partment  of  Defense  or  Federal  Government  management  responsibil¬ 
ity  for  a  Federal  Supply  Group/Federal  Supply  Class  (FSG/FSC), 
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commodity  or  item  by  a  single  agency.  Normally,  it  includes  com¬ 
putation  of  requirements,  and  the  functions  of  funding,  budgeting, 
storing,  issuing,  cataloging,  standardization  and  procuring. 

b.  Proposed  Purpose  of  SSR.  The  purpose  of  a  supply 
support  request  is  to  request  integrated  materiel  management 
support  from  an  IMM  including  the  following  actions: 

(1)  Item  Management  Coding  (IMC).  The  SSR  acts  as 
an  IMC  card  when  the  submitting  Component  has  not  previously 
coded  the  item  for  integrated  materiel  management.  The  IMM  is 
charged  with  the  responsibility  of  acting  as  the  Item  Management 
Classification  Agent  and  providing  cataloging  and  supply  support 
for  items  under  the  cognizance  of  the  IMM. 

(2)  Registration  of  User  Interest.  The  SSR  is  used 
to  request  the  addition  of  an  activity  as  a  user  of  an  item  when 
that  activity  has  not  been  previously  re  corded  in  the  re cords  of 
the  IMM  and  DLSC,  and  for  which  support  has  not  been  previously 
provided . 


(3)  Request  for  Supply  Support.  The  requesting 
activity  provides  a  forecast  of  retail  and  replenishment  quanti¬ 
ties  to  support  its  requirements  for  the  support  item  being  re¬ 
quested  to  the  IMM  to  determine  the  method  and  level  of  support 
to  be  provided.  Method  of  support  includes  the  method  of  man¬ 
agement  by  the  IMM  such  as  centrally  stocked,  or  centrally  pro¬ 
cured  but  not  stocked;  and  level  of  support  includes  the  quantity 
of  materiel  to  be  procured  and/or  stocked  to  support  the  supply 
support  request. 

(A)  Cataloging  Support.  The  SSR  provides  management 
and  technical  data  to  be  used  by  the  IMM  to  perform  the  following 
actions  : 


(a)  Item  Identification.  This  is  the  descrip¬ 
tion  of  the  item  in  relation  to  other  items  of  supply. 

(b)  Item  Entry  Control  (IEC).  Determination 
of  whether  the  item  already  exists  in  the  system  or  if  there  is 
a  suitable  substitute. 

(c)  NSN  Assignment.  IMM  requests  DLSC  to  as¬ 
sign  an  NSN  for  new  items  of  supply  for  which  integrated  materiel 
management  is  assumed. 

(d)  Catalog  Management  Data.  IMM  updates  the 
management  data  segment  of  DLSC  files  to  record  such  data  as 
unit  price,  unit  of  issue,  etc.,  and  to  publish  catalogs. 

c.  Applicability.  The  SSR  Procedures  should  be  man¬ 
datory  for  all  DoD  and  civil  agencies  in  requesting  supply  sup¬ 
port  for  consumable  items  and  no  other  procedures  should  be 
permitted . 
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SSR  Generation  Criteria 


Policies  and  procedures  for  generating  SSRs  are  contained 
in  the  IMM  Manual  (Appendix  D,  Reference  9),  DoDI  5100.63  (Appen¬ 
dix  D,  Reference  5),  DoDI  4140.42  (Appendix  D,  Reference  10)  and 
DoDD  4140.40  (Appendix  D,  Reference  19).  These  directives  are 
subject  to  interpretation  and  contain  conflicting  language  regard 
ing  the  criteria  for  generating  an  SSR,  particularly  for  items 
with  an  existing  stock  number.  The  criteria  and  procedure's  vary 
by  Component  and  sometimes  within  Component  for  generation  of 
SSRs  for  both  new  and  existing  items  of  supply.  Some  Components 
submit  requests  for  all  new  items  that  have  a  Source  Code  P  (pro¬ 
cured).  Other  Components  submit  a  request  only  if  a  P-coded 
item  has  a  quantitative  requirement  that  equals  or  exceeds  a 
specified  parameter. 

Some  SICCs  submit  an  SSR  for  an  existing  item  only  if 
the  submitting  activity  is  not  already  recorded  as  a  user  on  the 
item.  Other  Components  submit  an  SSR  for  an  existing  item  only 
if  the  requirements  exceed  a  specified  dollar  value  parameter. 
Some  Components  do  not  submit  an  SSR  for  an  item  if  the  require¬ 
ment  is  not  generated  during  the  provisioning  process;  an  IMC 
transaction  is  sent  instead. 

Another  aspect  of  the  problem  involves  the  generation 
and  submission  of  change  requirements.  The  same  directives  pre¬ 
viously  referenced  speak  to  the  submission  of  requests  for  ini¬ 
tial,  follow-on,  reprovisioning  and  phased  provisioning  in  a 
general  fashion.  The  statistics  generated  by  the  DODSSR  Study 
indicated  that  changes  of  any  type  constituted  less  than  one 
percent  of  the  total  SSRs  submitted  during  the  entire  data  col¬ 
lection  period.  Either  very  few  changes  are  being  submitted,  or 
those  that  are  submitted  are  sometimes  being  identified  as  an 
initial  submission. 

The  generation  criteria  for  SSRs  for  new  and  existing 
items  should  be  more  clearly  spelled  out  in  the  IMM  Manual  and 
in  DoDI  4140.42  to  cover  the  following  conditions: 

*  Initial  requests  for  new  and  existing  Items. 

*  Subsequent  submission  of  SSRs  as  initial  or  change 
transactions  to  cover  the  following  circumstances. 

Equipment  design  changes. 

Follow-on  provisioning  of  the  same  equipment  from 
the  same  contractor  under  a  different  contract. 

Re p r o v i s i on i ng  of  the  same  equipment  from  a  dif¬ 
ferent  contractor  under  a  different  contract. 
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Phased  provisioning  of  the  sain;  equipment  from  the 
same  contractor  under  a  formal  program. 

Requirements  for  the  same  equipment  from  the  same 
contractor  under  the  same  contract  with  equipment  deliveries 
spread  across  multiple  years. 

*  Nonprovisioning  requirements. 

The  policy  in  DoDD  4140.40  should  be  revised  to  confoim 
with  the  policy  in  DoDI  4140.42  and  the  IHM  Manual.  The  policies 
and  procedures  in  DoDI  5100.63  are  redundant  with  the  IMM  Manual 
and  the  directive  should  be  canceled  and  its  policies  and  proce¬ 
dures  incorporated  into  the  IMM  Manual. 

4 .  Method  of  Suppo r t / Le ve 1  of  Support  Determinations 


The  role  of  the  SICC  and  the  IMM  in  determining  the  method 
of  support  and  level  of  support  needs  to  be  clarified.  Currently 
the  supply  support  request  contains  certain  key  data  elements 
that  are  used  by  the  SICC  to  convey  information  to  the  IMM  that 
may  be  or  may  not  be  used  by  the  IMM  in  determining  the  method 
and  level  of  support  to  be  provided.  The  intent  of  the  entry 
and  use  of  these  data  elements  by  the  SICC  and  processing  and 
use  by  the  IMM  are  not  clear.  These  data  elements  are  discussed 
be  low . 


Method  of  support  in  this  sense  is  used  to  mean  whether 
the  item  will  be  stocked  or  not  stocked  in  the  supply  system, 
and  whether  it  will  be  centrally  or  locally  managed.  Level  of 
support  involves  the  determination  of  the  depth  or  quantity  of 
items  being  stocked.  A  policy  review  should  be  made  by  0ASD(MRA&L) 
to  determine  the  respective  roles  of  the  SICC  and  IMM  in  deter¬ 
mining  method  and  level  of  support. 

a.  Acquisition  Advice  Code  (AAC).  The  AAC  is  the  prin¬ 
cipal  vehicle  used  by  the  IMM  today  to  J"dicate  the  method  and 
to  a  certain  extent  the  level  of  support  being  provided  for  an 
item  of  supply.  The  supply  support  request  provides  for  the 
SICC  to  enter  an  AAC  J  for  new  items  of  supply  if  the  SICC  wants 
to  recommend  central  procurement  with  no  stockage.  DLA  will 
assign  AAC  J  to  an  item  as  the  method  of  support  if  J  is  received 
in  an  SSR.  An  IMM  may  send  notification  of  AAC  assignment  using 
the  advice  transaction  with  an  appropriate  Action  Taken  Code. 

The  quantity  fields  must  be  blank  when  an  AAC  J  is  entered  for  a 
new  item.  The  procedures  specify  that  an  AAC  may  be  entered  to 
recommend  stockage  for  existing  items  of  supply  if  the  item  is 
not  currently  being  managed  as  a  stocked  item.  There  are  no 
procedures  indicating  how  the  IMM  is  to  use  the  entry;  whether 
consideration  is  mandatory  or  optional.  Current  procedures  and 
usage  of  the  AAC  are  conflicting,  varied  and  vague.  This  code 
should  either  be  deleted,  combined  with  another  code,  or  defini¬ 
tive  procedures  and  criteria  for  its  entry  by  submitters  and 

179 


i 

v 


processing  by  receivers  should  be  provided.  Pending  policy  rul¬ 
ing  by  OASD,  it  is  recommended  that  the  following  entries  be 
permitted  by  the  SICC. 


(1)  AAC  D  -  Do D  integrated  materiel  managed,  stocked 

and  Issued . 


(2)  AAC  G  -  GSA  integrated  materiel  managed,  stocked 

and  issued. 


(3)  AAC  J  -  Centrally  procured,  but  not  stocked. 
Entry  should  be  permitted  when  quantity  fields  contain  other  than 
zero  as  well  as  zero. 


(4)  AAC  K  -  Centrally  stocked  for  overseas  only. 

(5)  AAC  L  -  Local  purchase  authorized. 

(6)  AAC  U  -  Insurance  item.  Note:  AAC  Z  currently 

identifies  both  insurance  and  numeric  stockage  objective  items. 

The  two  need  to  be  separately  distinguished,  since  different  rules 
are  used  in  migrating  items  from  numeric  stockage  objective  or 
insurance  to  demand  based  and  back. 


(7)  AAC  Z  -  Numeric  stockage  objective  item, 
b .  Replenishment  Quantity 

The  replenishment  quantity  is  described  by  the  SSR 
Procedures  as  the  quantity  of  the  item  which  the  SICC  anticipates 
will  be  required  for  replenishment  from  the  I  MM  distribution 
system  during  the  first  year  of  operation  of  end  items  provi¬ 
sioned  or  other  projects.  The  quantity  is  to  assist  the  IMM  in 
requirements  computation  to  ensure  that  adequate  wholesale  backup 
stocks  are  available  until  normal  demand  patterns  are  established. 
There  does  not  appear  to  be  too  much  controversy  that  this  is  a 
forecast  or  a  recommendation  from  the  SICC  to  the  IMM.  The  prob¬ 
lem  seems  to  be  the  variance  in  interpretation  of  what  is  to  be 
entered  into  this  field  and  how  it  is  to  be  used. 

If  100  equipments  are  being  procured,  with  10  to  be 
delivered  the  first  year,  25  the  second  year,  25  the  third  year 
and  40  the  fourth  year,  what  quantity  is  to  be  entered  into  this 
field?  Should  replenishment  quantities  based  upon  the  first 
year  only  be  entered  into  this  field?  If  so,  should  requests  be 
submitted  in  the  subsequent  years  for  the  other  requirements? 

Or  should  a  yearly  average  of  all  100  equipment  requirements  be 
entered  in  the  quantity  field.  If  requirements  for  each  year 
are  submitted  separately,  it  is  conceivable  that  the  anticipated 
demand  for  equipments  delivered  in  a  particular  year  would  be 
too  low  to  warrant  stockage,  but  the  anticipated  requirements  for 
year  one  plus  one  or  more  subsequent  years  would  warrant  stockage. 


Stockage  based  upon  demands  from  requisitions  may  take  too  long 
to  provide  responsive  support  for  the  large  equipment  deliveries 
in  later  years  . 

Another  question  that  arose  was  whether  the  replenish¬ 
ment  quantity  should  be  used  only  for  new  items  of  supply,  whether 
it  should  be  used  to  forecast  and  augment  wholesale  stocks  for 
existing  stocked  items,  or  whether  augmentation  of  stocks  for 
existing  items  should  be  based  solely  upon  the  retail  quantity. 

Clarification  should  be  provided  by  OASD(MRA&L)  on 
the  policy,  criteria  and  procedures  for  entry  of  data  in  this 
field  by  SICCs  and  upon  usage  of  this  field  by  the  IMM.  The 
clarified  policy,  criteria  and  procedures  should  be  incorporated 
into  DoDI  4140.42  and  into  the  IMM  Manual. 

c .  Retail  Quantity 


The  retail  quantity  is  described  in  the  SSR  Proce¬ 
dures  as  the  quantity  of  an  item  required  from  the  IMM  distribu¬ 
tion  system  to  satisfy  initial  support  requirements  during  the 
first  year  of  operation  of  the  end  item  provisioned,  commencing 
with  the  date  repair  parts  are  required  (DRPR) .  This  includes 
quantities  to  outfit  or  increase  levels  in  all  organizational, 
intermediate  and  depot  level  activities  supporting  the  end  item 
and  all  other  quantities  intended  to  be  requisitioned  by  the 
using  Component  for  Component  owned  retail  pipeline  stock  in 
support  of  the  end  item. 

The  same  problem  obtains  for  retail  quantity  for 
multiple  equipments  being  delivered  in  different  years.  Should 
the  quantity  be  averaged,  should  it  be  the  total  retail  require¬ 
ments  for  all  equipments  for  all  years,  or  should  the  quantity 
for  the  first  year  only  be  entered?  If  the  quantity  for  the 
first  year  only  is  entered,  should  initial  or  change  SSRs  be 
sent  for  the  subsequent  deliveries  in  later  years? 

There  seems  to  be  a  difference  of  opinion  among  SICCs 
and  IMMs  as  to  whether  the  retail  quantity  is  a  forecast  or  recom¬ 
mendation,  or  whether  it  is  a  mandatory  quantity  that  must  be 
supported  as  a  firm  requirement.  Should  the  retail  quantity  be 
treated  the  same  for  new  and  existing  items?  If  an  IMM  procures 
retail  stocks  for  new  items  that  are  going  to  be  stocked  by  the 
IMM,  should  the  IMM  also  procure  retail  stocks  for  new  items  that 
are  designated  for  central  procurement  but  not  stocked?  The  prac¬ 
tices  and  opinions  of  both  SICCs  and  IMMs  vary  for  both  replenish¬ 
ment  and  retail  quantities.  Policy,  criteria  and  procedures  for 
entry  by  submitters  and  processing  by  receivers  of  retail  quan¬ 
tities  should  be  clarified  for  retail  quantities  as  well  as  re¬ 
plenishment  quantities.  The  policy  review  should  also  consider 
whether  both  retail  and  wholesale  quantities  are  required  or 
whether  the  replenishment  quantity  can  be  forecasted  based  upon 
the  retail  quantity.  The  clarified  policy,  criteria  and  proce¬ 
dures  should  be  incorporated  into  DoDD  4140.42  and  the  IMM  Manual. 
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There  are  currently  two  data  elements  In  the  Program 
Data  Supply  Support  Request  (PDSSR)  to  indicate  the  designation 
of  the  end  item  or  system  in  which  a  repair  part  is  contained. 

The  end  item  name,  NSN,  type  or  model  number  may  be  entered.  The 
quantitative  analysis  indicated  that  the  entry  of  this  data  ele¬ 
ment  was  quite  inconsistent  and  relatively  useless  as  a  valid 
identification  element  for  an  end  item  or  system.  Although  the 
entry  could  sometimes  be  understood  on  a  manual  basis,  the  varia¬ 
tions  in  entry  of  the  same  designation  made  it  virtually  impos¬ 
sible  to  use  on  an  automated  basis. 

There  is  also  a  provision  for  entry  of  a  weapon 
system  code  (WSC)  in  the  PDSSR.  This  code  is  an  optional  entry 
of  codes  assigned  to  selected  weapon  systems  under  Enclosure  1 
of  DLAR  4140.38  (Appendix  D,  Reference  28).  The  code  is  to  be 
entered  in  the  PDSSR  when  the  SSR  submitter  desires  to  advise 
the  IMM,  otherwise  the  field  is  to  be  left  blank.  The  quanti¬ 
tative  analysis  indicated  that  blanks  were  entered  about  93%  of 
the  time.  Of  75  different  code  entries  12  were  valid  codes  and 
63  were  invalid,  i.e.,  the  codes  were  not  listed  on  the  enclo¬ 
sure  to  the  regulation.  Although  the  SSR  Procedures  reference 
the  Weapon  System  Regulation,  there  are  no  procedures  pertaining 
to  the  use  of  the  code  by  either  the  SICC  or  the  IMM  and  there 
is  no  known  usage  under  the  current  system. 

A  DL A  letter  of  18  May  1  977  (Appendix  D,  Reference 
29)  refers  to  the  DLA  Weapon  System  Regulation  and  outlines  a 
procedure  for  the  Military  Services  to  nominate  selected  weapon 
systems  to  be  covered  by  the  provisions  of  the  Weapon  System 
Letter.  The  nominations  are  to  be  identified  by  Provisioning 
Control  Code  (PCC)  not  WSC.  After  approval  by  DLA,  the  SSR  sub¬ 
mitter  is  advised  to  use  the  code  in  the  PDSSR  and  the  Defense 
Supply  Center  will  recognize  the  code  in  combination  with  the 
submitting  activity  code.  The  procedures  in  the  letter  provide 
for  special  stockage  consideration  of  items  identified  to  an 
approved  weapon  system.  The  special  stockage  consideration  pro¬ 
vides  for  initial  stockage  of  items  that  would  not  normally 
qualify  for  stockage  under  the  stockage  criteria  published  in 
DoDD  4140.42. 

The  WSC  as  currently  entered  into  the  SSR  has  no  real 
meaning  or  usage,  since  the  PCC  is  being  used  in  the  SSR  to  iden¬ 
tify  items  as  essential  to  weapons  systems  for  priority  processing 
and  initial  stockage  considerations.  The  PCC  is  supposed  to  be 
a  control  data  element  to  control  the  sequencing  and  processing 
of  SSRs,  not  an  end  item  designator  per  se ■  It  would  appear  that 
a  meaningful  end  item  designator  should  be  established  that  will 
permit  identification  of  individual  items  to  the  end  item  in  which 
it  is  contained  not  only  for  the  purpose  of  making  method  of 


su p p o r t / le ve 1  of  support  decisions,  but  to  provide  an  automated 
audit  trail  of  association  of  the  supply  support  determinations 
on  individual  support  items  in  an  end  item  in  order  to  provide 
status  of  support  on  an  end  item  or  system  basis  as  well  as  on 
an  individual  item  basis. 

The  Army,  Navy  and  Air  Force  currently  are  using  two- 
digit  codes  to  identify  the  application  of  support  items  to  end 
items,  systems  or  programs.  These  codes  are  described  in  the 
DIDS  Manual  (Appendix  D,  Reference  25)  Tables  60,  65  and  66,  with 
an  assigned  Data  Record  Number  (DRN),  description  of  the  usage 
of  the  codes,  and  conventions  for  their  maintenance  and  publica¬ 
tion.  It  is  felt  that  the  use  of  these  codes  would  provide  a 
better  identification  of  items  to  their  application  since  it 
would  be  more  meaningful  to  the  Services  in  terras  of  their  on¬ 
going  systems  and  would  provide  a  more  precise  meaning  to  the 
IMMs.  These  codes  couid  be  used  to  identify  item  application 
for  audit  trail  purposes  and  in  making  method  of  support /level 
of  support  determinations. 

The  codes  are  the  Navy's  Special  Material  Identifica¬ 
tion  Codes  (SMICs),  the  Army's  Special  Group/Weapons  System/End 
Items  Code  portion  of  their  Materiel  Category  Codes,  and  the  Air 
Force's  Materiel  Management  Aggregation  Codes  (MMACs).  These 
codes  should  be  entered  into  each  line  item  request  and  the 
Weapon  System  Code  in  the  PDSSR  should  be  abolished. 

e .  Source  Codes 


Source  Codes  are  part  of  the  Source,  Maintenance  and 
Recoverability  (SM&R)  Codes.  The  source  codes  are  assigned  tc 
support  items  to  indicate  the  manner  of  acquiring  items  for  the 
maintenance,  repair  or  overhaul  of  end  items.  The  SSR  Procedures 
specify  the  entry  of  codes  in  the  P_  series  (procured).  The  pro¬ 
cedures  do  not  specify  the  reason  for  entry  of  the  code  by  the 
SICC  or  the  use  of  the  code  by  the  I  MM.  Currently,  DLA  is  the 
only  known  user  of  this  code.  If  a  PB  Source  Code  (Insurance 
Item)  is  entered,  DLA  will  stock  the  item  as  an  insurance  item 
if  the  SICC  has  not  recommended  the  item  for  central  procurement 
without  stockage. 

The  quantitative  evaluation  indicated  that  there  was 
a  wide  variation  in  the  application  and  usage  of  Source  Code  PB. 
Acquisition  Advice  Code  Z  also  indicates  that  an  item  is  an  in¬ 
surance  item,  but  the  use  of  Code  Z  may  mean  that  the  item  is  a 
numeric  stockage  objective  item.  There  is  a  space  in  the  SSR 
for  entry  of  the  AAC ,  however,  if  the  item  is  not  an  active  NSN 
item  the  only  provision  is  for  the  SICC  to  enter  an  KAC  J  to 
recommend  central  procurement  and  not  stocked.  Even  if  the  pro¬ 
cedures  permitted  the  entry  of  AAC  Z,  the  only  way  to  tell  if 
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the  item  was  '  v  recommended  as  an  insurance  or  numeric  stock- 

age  objective  i  would  be  to  check  the  source  code  for  the 

presence  or  abse  oe  of  Code  PB,  which  is  a  rather  cumbersome  and 
roundabout  process  to  permit  a  determination  of  the  condition. 

The  need  for  a  SICC  to  designate  an  item  as  an  in¬ 
surance  or  numeric  stockage  objective  item  and  the  usage  of  the 
designation  by  the  IMM  should  be  clarified  by  OASD(MRA&L).  Our 
research  indicated  that  the  Service  Components  expressed  a  desire 
to  convey  the  intelligence  that  an  item  was  an  insurance  item  or 
a  numeric  stockage  objective  item  to  the  IMM  and  that  the  IMM 
consider  this  intelligence  in  their  method  of  support / level  of 
support  determinations.  Pending  policy  clarification  by 
OASD(MRASrL)  ,  the  study  group  recommends  that  a  single  method  be 
used  to  convey  this  information.  It  is  recommended  that  AAC  Z 
be  used  to  convey  this  information  and  that  the  source  code  be 
eliminated  because  of  the  variability  of  its  use  and  understand¬ 
ing  for  supply  purposes.  The  definition  of  AAC  Z  should  be 
revised  to  split  out  insurance  and  numeric  stockage  objective 
designations.  It  is  recommended  that  a  new  AAC  Code  U  be  as¬ 
signed  to  designate  insurance  items  with  AAC  Z  used  to  designate 
numeric  stockage  objective  items. 

f •  Essentiality 

During  our  headquarters  and  field  research  the  Mili¬ 
tary  Services  indicated  a  requirement  to  communicate  essentiality 
to  IMMs  for  consideration  in  stocking  items  because  the  items 
were  essential  to  a  critial  application.  Various  correspondence 
among  the  Services,  DLA  and  OASD  also  addressed  this  requirement. 
There  are  a  number  of  factors  involved  in  the  consideration  of 
essentiality.  The  essentiality  of  a  support  item  to  the  next 
higher  assembly  or  equipment,  the  essentiality  of  the  equipment 
and/or  the  essentiality  of  an  equipment  or  weapon  system  because 
of  a  particular  mission  or  application.  In  addition,  there  is 
the  question  of  the  responsibility  of  the  SICC  and  the  IMM  in 
the  identification,  assignment  and  use  of  essentiality  for  con¬ 
sideration  in  initial  stockage  decisions  and  follow-on  replenish¬ 
ment  . 


There  is  no  direct  method  of  communication  of  essen¬ 
tiality  in  the  SSR  under  the  current  system.  However,  there  are 
a  number  of  data  elements  that  could  be  used,  or  are  being  used, 
to  denote  or  connote  essentiality.  Some  of  these  vehicles  are 
being  used  under  the  current  system  in  method  of  support / level  of 
support  determinations.  The  definitions  of  insurance  and  numeric 
stockage  objective  items  include  the  word  essentiality.  The 
source  code  PB  designates  an  item  as  an  insurance  item.  AAC  Z 
designates  an  item  as  either  a  numeric  stockage  objective  item 
or  an  insurance  item.  The  use  of  a  weapon  system  code  with  a 
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reference  Co  the  weapon  system  program  regulation  connotes  essen¬ 
tiality  on  an  equipment  basis,  although  the  PCC  is  used  In  place 
of  the  WSC  to  provide  special  stockage  considerations  for  supply 
support  requests  for  items  in  approved  weapon  systems. 

The  determination  of  the  responsibilities  of  the 
SICCs  and  IMMs  in  identifying  items  or  equipment  as  essential, 
the  definition  of  essentiality  and  the  rules  for  application  of 
essentiality  by  SICCs  and  IMMs  in  method  of  support  and  level  of 
support  decisions  by  SICCs  and  IMMs  is  beyond  the  scope  of  the 
DODSSR  Study.  The  study  team  recognizes  the  potential  need  for 
using  essentiality  for  initial  stockage  and  follow-on  replenish¬ 
ment  considerations.  It  is  recommended  that  OASD(MRA&L)  conduct 
a  policy  review  in  conjunction  with  the  Components  to  determine 
the  need  for  the  designation  of  items  as  essential  and  to  estab¬ 
lish  policy  and  criteria  for  the  identification,  definition  and 
application  of  essentiality  to  support  items  and  equipments  and 
to  develop  rules  for  its  usage  in  initial  and  follow-on  stockage 
considerations.  The  policy,  criteria  and  rules  should  then  be 
incorporated  into  DoD  4140.42,  the  IMM  Manual,  and  DLAR  4140.38 
weapon  systems  support  requirements. 

The  DODSSR  Study  Team  is  concerned  with  the  conven¬ 
tion  used  to  convey  essentiality  in  the  SSR.  It  is  felt  that  a 
single  direct  and  simple  method  should  be  used  in  the  SSR  that 
will  convey  item  and  equipment  essentiality.  Pending  the  comple¬ 
tion  of  the  OASD(MRAfitL)  policy  review  it  is  recommended  that  the 
essentiality  codes  contained  in  MIL-STD-1552  be  used  to  convey 
item  essentiality.  This  is  a  one-digit  code  that  Indicates  the 
degree  to  which  the  failure  of  the  part  affects  the  ability  of 
the  end  item  to  perform  its  Intended  operations.  These  are  stan¬ 
dard  codes  that  have  a  standard  definition  that  have  been  coor¬ 
dinated  among  the  Components.  These  codes  can  be  used  in  combina¬ 
tion  with  the  system  designator,  recommended  by  the  DODSSR  Study, 
to  relate  item  essentiality  with  end  item  or  system  essentiality, 
and  to  apply  this  relationship  when  making  initial  and  follow-on 
stockage  determinations. 

5 .  Accumulation  of  Requirements 

Currently  the  decision  to  stock  a  part  numbered  item  or 
to  change  the  stockage  decision  of  an  existing  item  are  made 
based  upon  the  consideration  of  individual  supply  support  re¬ 
quests.  The  SICCs  feel  that  too  many  items  are  being  classified 
as  centrally  procured  and  not  stocked.  The  SICCs  feel  that 
these  items  will  experience  demand  and  that  it  takes  too  long  to 
convert  an  item  from  centrally  procured  to  stocked  on  the  basis 
of  subsequent  demand  from  requisitions.  The  SICCs  recommend 
that  the  IMMs  accumulate  demand  contained  in  the  SSRs  over  time, 
and  change  the  management  decision  to  centrally  stocked  if  the 
accumulated  demand  warrants  it. 
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The  incidence  of  duplicetion  of  control  numbers  for  the 
same  items  and  occurrence  of  SSRs  with  the  same  PCC  with  differ¬ 
ent  item  serial  numbers  for  the  same  item  on  the  same  day  or  in 
the  same  cycle  indicates  that  the  SICCs  are  not  attempting  to 
roll  up  demand  for  the  same  item  across  PCCs  or  even  within  the 
same  PCC.  Generally  speaking,  the  IMMs  make  stockage  determina¬ 
tions  based  upon  the  consideration  of  individual  SSRs  and  do  not 
make  any  attempt  to  roll  up  SSRs  or  to  maintain  a  history  of 
requirements  for  the  same  item  for  future  stockage  considerations. 

Some  consideration  should  be  given  to  the  rolling  up  of 
demand  by  the  SICC  prior  to  su bmit t ing  .  the  SSR  and  by  the  IMM  in 
rolling  up  demands  for  the  same  item  in  the  same  processing  cycle 
and  accumulating  demands  in  SSRs  over  a  forecast  period.  It 
would  appear  that  the  SICC  should  consider  repetitiveness  of 
demand  for  items  within  the  same  PCC  for  the  same  activity.  The 
IMM  should  consider  demands  for  the  same  item  for  different  PCCs 
for  the  same  activity  and  demands  for  the  same  item  for  different 
activities. 

The  DODSSR  Study  did  not  attempt  to  quantify  the  poten¬ 
tial  for  rolling  up  or  accumulating  demand  because  the  require¬ 
ments  determination  processes  for  computing  the  range  and  depth 
of  item  requirements  are  outside  the  scope  of  the  study.  An 
extract  could  be  made  of  SSR  suspense  files  by  SICCs  and  IMMs 
over  a  forecast  period.  The  selected  SSRs  could  then  be  pro¬ 
cessed  through  the  programs  currently  used  to  compute  range  and 
depth  requirements.  The  SSRs  could  be  first  processed  through 
individually  as  is  the  case  today.  The  selected  SSRs  could  then 
be  rolled  up  and  the  summed  quantities  processed  through  the 
computation  programs  to  determine  the  number  and  percent  of  items 
that  would  be  stocked  If  the  demand  were  accumulated.  This  pro¬ 
cess  could  be  accomplished  using  the  existing  computation  programs 
in  the  teat  mode  without  affecting  existing  records  for  active 
items  and  without  extensive  reprogramming.  The  results  of  the 
test  would  then  form  the  basis  for  determining  whether  accumula¬ 
tion  or  roll  up  of  SSRs  demand  should  be  performed  by  the  SICC 
or  the  IMM  on  a  continuing  basis. 

6 .  Funding  of  Requirements 

The  policy  contained  in  DoD  directives  is  not  clear  as 
to  who  has  the  responsibility  for  budgeting  and  funding  requlre- 
cents  contained  in  SSRs.  The  following  directives  apply: 

DoDD  4240.26,  Integrated  Materiel  Management  for 
Consumable  Items 

DoDD  4140.40,  Basic  Objectives  and  Policies  on 

Provisioning  of  End  Items  of  Materiel 
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DoDI  4140.42,  Determination  of  Initial  Requirements 
for  Secondary  Items 

DoDI  5100.63,  Provisioning  Relationships  Between  the 
Military  Departments  and  Defense 
Agencies  and  Commodity  Integrated 
Materiel  Managers 


It  appears  to  be  clear  that  the  IMMs  have  the  responsi¬ 
bility  for  budgeting  and  funding  for  the  replenishment  quantity. 
However,  the  language  in  the  referenced  directives  is  ambiguous 
for  the  retail  quantity.  When  an  item  is  accepted  for  supply 
support  by  DLA,  and  the  item  is  managed  as  a  stocked  item,  DLA 
considers  the  retail  quantity  and  budgets,  funds  and  procures  a 
retail  quantity  based  upon  the  retail  quantity  contained  in  the 
SSR.  However,  if  a  new  item  is  classified  as  not  stocked,  the 
SICC  must  send  a  funded  requisition  or  MIPR  180  days  in  advance 
of  the  date  of  need  of  the  requirement.  This  appears  to  be  some¬ 
what  inconsistent  with  the  advance  procurement  and  stockage  of 
retail  requirements  for  items  designated  for  stockage.  Also, 
the  requirement  to  send  a  funded  document  180  days  in  advance  of 
the  need  date  may  be  somewhat  unrealistic  considering  that  the 
SICC  must  wait  for  an  NSN  prior  to  requisitioning  the  item  and 


the  leadtime  for  the  item  may  be  less  than  180  days.  In  compar¬ 
ison,  there  does  not  appear  to  be  any  180  day  constraint  on  the 
SICCs  involving  the  procurement  and  requisitioning  of  stocked 
items  whether  they  are  new  or  existing  items. 

OASD(MRASL)  should  review  the  policy  on  financing  SSR 
requirements  and  clarify  the  policy  in  the  referenced  directives 
Consideration  should  be  given  to  the  funding  of  the  retail  re¬ 
quirement  by  the  IMM  or  making  the  SSR  a  funded  document  for  the 
retail  portion  of  the  requirement.  It  would  appear  logical  to 
treat  the  retail  requirement  for  stocked  and  not  stocked  items 
the  same  regardless  of  whether  the  retail  quantity  is  funded  by 
the  SICC  or  the  IMM. 


7 .  Technical  Data  Requirements 


The  lack  of  technical  data  was  cited  throughout  the  study 
as  one  of  the  major  problem  areas  in  supply  support  request  pro¬ 
cessing.  SICCs  complained  of  the  difficulty  in  obtaining  tech¬ 
nical  data  from  contractors  and  the  failure  to  receive  technical 
data  from  contractors.  IMMs  complained  that  technical  data  fre¬ 
quently  was  not  received  from  the  SICCs  and  that  in  many  cases 
when  it  was  received,  it  was  Insufficient  to  obtain  a  stock  num¬ 
ber  for  the  item,  let  alone  perform  item  entry  control  functions. 
In  addition  to  the  availability  of  technical  data,  and  the  qual¬ 
ity  of  the  technical  data  for  use  in  technical  operations,  another 
problem  experienced  by  the  study  group  during  the  AUTODIN/TELEFAX 
Test  was  the  legibility  of  the  technical  data.  The  legibility 
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of  the  technical  data  being  received  was  questionable  for  manual 
use  of  the  hard  copy  as  received  and  even  more  so  for  use  in 
making  an  aperture  card  to  be  placed  in  a  technical  library  or 
for  electrical  transmission  from  one  location  to  another. 

The  statistics  generated  by  the  study  group  confirmed 
that  technical  data  was  available  for  part  numbered  items  only 
about  401  of  the  time.  The  question  arises  as  to  whether  con¬ 
tracts  are  clearly  specifying  the  requirement  for  technical  data, 
the  conditions  under  which  technical  data  is  available  even  if 
it  is  a  contractual  requirement  and  the  purpose  for  which  tech¬ 
nical  data  is  required.  The  study  team  Intended  to  pursue  a 
study  subset  to  research  the  availability  of  technical  data,  the 
quantity  and  quality  of  technical  data  being  received  and  the 
requirement  for  technical  data  from  a  SICC  and  an  IMM  standpoint. 
Resources  were  requested  from  some  of  the  Components  to  perform 
the  research,  however,  the  specialized  technical  personnel  quali¬ 
fied  to  make  such  a  review  were  not  made  available  to  the  study 
group.  Technical  personnel  were  needed  from  both  SICCs  and  IMMs 
to  pursue  this  research  on  an  objective  basis.  When  the  resources 
were  not  provided,  the  study  team  cancelled  the  review  of  tech¬ 
nical  data. 

It  is  still  felt  that  a  study  of  the  usage  of  technical 
data  should  be  conducted.  It  is  recommended  that  0ASD(MRA&L) 
establish  a  policy  review  of  logistics  technical  data.  The 
definition  and  purpose  of  technical  data  should  be  studied  and 
requirements  established  for  its  acquisition,  use  and  retention 
for  the  following  categories  of  usage: 

Selection  of  maintenance  significant  items. 

-  Item  entry  control. 

Catalog  identification. 

-  Purchase  description. 

8 .  Supply  Support  Request  Cycle 

At  the  beginning  of  the  study,  the  study  team  attempted 
to  establish  boundaries  around  the  supply  support  process  to 
govern  the  scope  of  the  study  research.  An  attempt  was  made  to 
determine  when  the  supply  support  request  process  started  and 
when  it  was  considered  complete.  The  answers  received  to  this 
question  of  when  the  process  started  and  when  it  was  complete 
were  quite  varied. 

The  most  common  and  logical  answer  received  from  SICC 
activities  was  that  the  process  started  after  maintenance  signif¬ 
icant  items  were  selected  and  the  maintenance  significant  items 
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had  been  item  management  coded  for  integrated  materiel  manage¬ 
ment.  At  this  time  it  is  now  within  the  capability  of  the  S1CC 
to  determine  specific  quantitative  requirements  and  to  prepare 
an  SSR  containing  the  necessary  management,  technical  and  control 
data  to  be  submitted  to  the  XMM. 

The  most  common  answer  from  both  SICCs  and  IMMs  as  to 
’.he  completion  of  the  process  was  upon  receipt  of  final  advice. 
However,  the  interpretation  of  what  constitutes  final  advice 
varied  among  both  SICCs  and  IMMs.  Under  some  interpretations,  a 
final  advice  could  constitute  a  reject,  reply  to  an  offer,  noti¬ 
fication  of  an  NSN  assignment  or  acceptance  of  a  request  for  an 
NSN  item.  The  real  key  to  answering  the  question  is  when  has 
support  been  accepted,  and  when  can  materiel  be  requisitioned, 
and  when  will  materiel  be  available  for  delivery  to  using  activ¬ 
ities?  In  other  words  when  does  the  IMM  assume  responsibility 
for  support  of  the  item. 

Under  the  current  system  the  SSR  submitter  is  required 
to  provide  a  date  repair  parts  are  required  and  the  IMM  is  sup¬ 
posed  to  provide  a  new  support  date  if  the  requested  support 
date  cannot  be  met.  The  current  procedures  do  not  permit  an  IMM 
to  provide  a  new  support  date  for  an  active  item  managed  by  an 
IMM.  It  is  presumed  that  the  IMM  accepts  the  item  immediately 
for  support  at  the  time  a  request  for  an  NSN  item  is  accepted 
regardless  of  the  stock  position  for  the  item,  unless  the  item 
is  classified  as  centrally  procured,  but  not  stocked. 

If  the  IMM  cannot  meet  the  requested  support  date  for  a 
new  item,  the  IMM  may  provide  a  new  support  date  to  the  SICC, 
while  authorizing  the  SICC  to  procure  retail  requirements  if  the 
support  date  is  not  satisfactory.  The  distinction  between  the 
authorization  of  the  SICC  to  procure  retail  requirements  for  new 
items,  but  not  for  existing  items  is  not  understood.  It  would 
appear  that  the  stock  position  and  leadtime  for  acquiring  stock 
would  dictate  the  support  date  for  existing  items  just  as  much 
as  it  does  for  neu  items.  The  study  team  could  not  assess  the 
frequency  of  procurement  of  retail  requirements  when  new  support 
dates  are  established  for  new  items  because  the  SICCs  are  not 
required  to  advise  the  IMM  of  the  amount  of  the  retail  quantity 
that  is  purchased. 

The  support  date  in  the  SSR  is  somewhat  analogous  to  the 
effective  date  of  transfer  for  logistic  transfers  from  one  man¬ 
ager  to  another.  The  principal  interest  in  the  support  date  by 
the  SICC  is  to  determine  when  materiel  may  be  requisitioned  to 
fill  the  retail  requirements.  The  biggest  concern  is  for  part 
numbered  items,  since  current  policy  discourages  part  numbered 
requisitions.  The  Defense  Logistics  Agency  does  not  generally 
initiate  procurement  action  for  new  items  until  the  stock  number 


189 


has  been  assigned  to  an  item.  The  SICCs  are  used  to  Provisioned 
Items  Orders  (PIOs)  being  placed  on  the  end  item  contractor  for 
new  retained  items  prior  to  the  assignment  of  a  stock  number. 

The  stock  number  is  furnished  to  the  contractor  prior  to  delivery 
of  the  repair  parts. 

A  current  provisioning  objective  as  stated  in  DoDI  4140.40 
(Appendiix  D,  Reference  19)  is  to  program  sufficient  time  into 
the  provisioning  process  to  perform  cataloging  operations  incident 
to  having  support  items  received  at  maintenance  and  supply  activ¬ 
ities  with  NSNs.  To  meet  this  objective  the  SICC  has  an  obliga¬ 
tion  to  submit  SSRs  sufficiently  in  advance  of  the  support  date  to 
permit  the  1MM  to  perform  its  provisioning,  cataloging  and  procure 
■eut  actions  in  order  to  receive  materiel  into  the  IMM  distribu¬ 
tion  system  by  the  support  date.  The  quantitative  analysis  indi¬ 
cated  that  the  DRPRs  being  provided  by  SICCs  were  not  realistic 
in  teras  of  the  production  leadtime  of  the  items  for  which  SSRs 
were  being  submitted  resulting  in  advice  from  the  IMM  with  new 
support  dates. 

The  DRPR  is  defined  in  the  SSR  Procedures  as  the  date 
that  materiel  must  be  in  the  IMM's  supply  system  to  support  re¬ 
quisitions  submitted  by  the  users  of  the  end  item.  The  IMM  is 
allotted  60  days  from  the  date  of  receipt  of  the  SSR  to  perform 
its  actions  and  obtain  an  MSN  and  provide  notification  to  the 
SICC.  The  SICC  is  authorized  to  followup  for  an  NSN  70  days 
after  submission  of  the  request  transaction.  The  IMM  is  allowed 
15  days  to  respond  to  the  followup  for  NSN  advice.  If  the  SICC 
has  received  an  initial  accept  for  a  part  number  item,  the  respons 
to  the  followup  does  not  contain  an  NSN,  or  if  no  response  is 
received  in  15  days;  it  is  reasoned  that  the  SICC  should  be  per¬ 
mitted  to  requisition  items  using  part  numbers  in  order  to  re¬ 
ceive  materiel  by  its  operational  need  date.  The  IMM  should  be 
required  to  maintain  a  reference  capability  to  cross  reference 
the  part  number  requisition  to  items  for  which  supply  support  has 
been  accepted  but  for  which  an  NSN  is  pending. 

9.  Transmission 


The  research  by  the  DODSSR  Study  Team  Including  system 
design  review,  operational  implementation  review,  data  collec¬ 
tion  and  analysis,  and  the  AUT0D1N/TELEFAX  Test  clearly  indicate 
the  advantage  of  electrically  transmitting  SSR  transactions  that 
do  not  require  technical  data  over  AUTODIN.  This  Includes  the 
following  categories  of  items: 

Items  with  stock  numbers. 

Permanent  system  control  number  items. 
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Part  number  items  for  which  technical  data  is  not 
required  or  will  not  be  supplied. 

The  advantages  of  submitting  technical  data  electrically 
can  be  realized  only  if  the  data  can  be  easily  and  rapidly  trans¬ 
mitted  with  the  received  image  being  of  a  quality  that  approaches 
the  requirements  for  entry  into  the  technical  data  library.  The 
TELEFAX  system  tested  did  not  meet  these  requirements,  but  the 
concept  of  electrical  transmission  has  potential  and  should  con¬ 
tinue  to  be  explored. 

The  advantages  of  mailing  technical  data  while  sending 
the  SSR  transaction  over  AUTODIN  are  not  so  obvious  as  the  case 
for  those  items  not  requiring  technical  data.  However,  there 
appears  to  be  a  potential  for  a  decrease  in  total  processing  time, 
as  well  as  an  increase  in  control  if  the  technical  data  is  pro¬ 
perly  marked  with  control  data,  at  a  minimum  the  PCC,  ISN,  and 
submitting  activity,  and  submitted  as  early  as  possible  by  the 
SICC,  including  the  consideration  of  mailing  the  technical  data 
after  potential  SSR  candidates  are  known,  but  prior  to  generation 
of  the  SSR  transaction.  The  item  name  should  be  supplied  with 
the  SSR  transaction.  A  method  of  following  up  for  technical  data 
should  be  established  and  a  management  report  developed  to  show 
information  pertaining  to  the  instance  of  items  where  technical 
data  was  received  when  required,  frequency  of  followups,  response 
to  followups  and  final  technical  data  received.  Goals  should  be 
be  established  and  a  copy  of  the  report  should  be  provided  by 
the  IMM  to  each  of  the  SICCs  in  order  to  monitor  and  control  the 
process . 

The  SSR  procedures  and  systems  should  be  revised  in 
accordance  with  the  following  recommendations. 

a.  All  supply  support  requests  for  which  technical  data 
is  not  required  should  be  sent  over  AUTODIN  using  the  most  direct 
Interface  between  computer  operations  and  AUTODIN  operations  avail¬ 
able  at  the  sending  and  receiving  activities.  Item  name  informa¬ 
tion  should  be  provided  for  all  items  forwarded  over  AUTODIN.  An 
early  Implementation  date  should  be  provided  for  this  recommenda¬ 
tion  since  it  can  be  easily  implemented  by  all  activities  pos¬ 
sessing  AUTODIN  terminals. 

b.  Procedures  and  systems  at  SICCs  and  IMMs  should  be 
revised  to  transmit  SSR  part  numbered  items  for  which  technical 
data  is  required  and  available  over  AUTODIN  with  the  technical 
data  marked  with  control  data  submitted  via  priority  mail  as 
soon  as  SSR  candidates  are  selected. 

c.  A  followup  and  reporting  procedure  should  be  estab¬ 
lished  to  monitor  and  control  the  transmission  and  receipt  of 


technical  data.  A  procedure  for  following  up  for  technical  data 
should  be  established.  A  management  report  should  be  developed 
to  provide  measurement  of  the  time  of  submission/receipt  of  tech¬ 
nical  data  and  to  monitor  and  control  this  process. 

d.  A  further  exploration  should  be  made  of  the  potential 
for  electrical  transmissions  of  technical  data. 

D .  PROCEDURES 

1 .  Introduction 

The  policies  and  responsibilities  for  integrated  materiel 
management  of  consumable  items  are  contained  in  DoDD  4140.26 
(Appendix  D,  Reference  16).  This  directive  authorizes  the  pub¬ 
lication  of  an  operating  procedures  manual  for  integrated  manage¬ 
ment  of  consumable  items.  Two  volumes  are  authorized,  one  for 
commodity  oriented  and  one  for  weapon  system  oriented  items.  The 
requirement  for  supply  support  requests  emanates  from  the  require¬ 
ment  to  provide  integrated  logistics  support  for  systems  and 
equipments.  Most  of  the  supply  support  requests  are  generated 
through  the  provisioning  process  governed  by  DoDD  4140.40  (Appen¬ 
dix  D,  Reference  19)  and  DoDI  5100.63  (Appendix  D,  Reference  5). 
The  provisioning  directives  in  conjunction  with  the  directive 
providing  guidance  on  the  determination  of  Initial  requirements 
for  support  items,  DoDI  4140.42  (Appendix  D,  Reference  10)  con¬ 
tain  policy  on  the  generation  of  supply  support  request  require¬ 
ments,  which  are  to  be  submitted  under  the  operating  procedures 
contained  In  the  IMM  Manual. 

a.  Volume  I  of  the  IMM  Manual  contains  procedures  for 
commodity  oriented  consumable  items  and  includes  the  following 
coverage . 

(1)  Chapter  1  is  a  general  chapter  containing 
authority,  purpose,  applicability,  responsibilities  and  adminis¬ 
trative  subjects. 

(2)  Chapter  2  contains  item  management  coding  cri¬ 
teria. 

(3)  Chapter  3  contains  item  management  coding  and 
classification  procedures. 

(4)  Chapter  4  contains  supply  support  request  pro¬ 
cedure  s  . 

(5)  Chapter  5  contains  exemption  procedures  from 
integrated  materiel  management. 
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(6)  Chapter  6  contains  logistic  reassignment  proce¬ 
dures  . 

(7)  Chapter  7  contains  reporting  and  auditing  proce¬ 
dures  • 

(8)  Chapter  8  contains  financial  operations  proce¬ 
dures  • 

(9)  The  appendices  contain  detail  criteria,  proce¬ 
dures,  instructions,  formats  and  codes  that  apply  to  the  individ¬ 
ual  chapters. 

b.  Volume  II  of  the  IMM  Manual  contains  procedures  for 
weapon  system  oriented  items  and  Includes  the  following  coverage. 

(1)  Chapter  1  contains  the  introductory  material. 

(2)  Chapter  2  contains  item  assignment  procedures. 

(3)  Chapter  3  contains  logistic  reassignment. 

(4)  Chapter  4  contains  supply  operations  procedures. 

(5)  Chapter  5  contains  technical  operations  proce¬ 
dures  . 

(6)  Chapter  6  contains  financial  operations  proce¬ 
dures  . 

(7)  The  appendices  contain  detail  criteria,  proce¬ 
dures,  instructions,  formats  and  codes  that  apply  to  the  Indivi¬ 
dual  chapters. 

Chapter  4  and  Appendix  E  of  Volume  1  of  the  IMM  Manual 
contain  the  supply  support  request  procedures  that  implement  the 
policies  contained  in  the  integrated  materiel  management  and  pro¬ 
visioning  directives.  As  discussed  in  Chapter  IV,  Volume  I,  of 
this  Report,  the  SSR  Procedures  constitute  the  functional  require¬ 
ments  statement  which  was  used  by  the  Components  to  design  systems 
to  generate,  transmit,  process  and  control  SSRs.  The  SSR  Proce¬ 
dures  provide  a  set  of  conventions  consisting  of  card  formats, 
data  elements  and  definitions,  and  codification  Instructions  for 
mandatory,  conditional  or  optional  entry  of  data  into  card  for¬ 
mats  • 

A  review  and  analysis  of  the  SSR  Systems  that  were  de¬ 
signed  and  implemented  by  the  Components  indicated  that  these 
systems  contained  some  basic  problems.  Some  of  these  problems 
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are  attributable  to  the  system  design  per  se .  Others  are  attrib¬ 
utable  to  management  or g an i z a t i ona 1 / f u nc t iona 1  differences,  while 
some  are  caused  by  the  lack  of  clear  policy  statements  for  cer¬ 
tain  critical  areas.  However,  the  SSR  Procedures  as  written, 
are  a  primary  factor  in  many  of  the  problems  being  experienced. 
Although  the  procedures  provide  punched  card  formats,  they  appear 
to  be  oriented  to  a  manual  batch  processing  user,  or  a  sequential 
batch  process  computer  system  with  excessive  manual  intervention. 
The  procedures  need  to  be  restructured  and  written  to  accommodate 
the  typo  of  automated  computer  systems  available  today  at  the 
principal  SSR  processing  activities.  In  other  words,  "the  system 
requirement  should  drive  the  functional  requirment”  as  opposed 
to  "the  procedures  driving  the  system." 

Part  1  of  this  Chapter  contains  a  summary  analysis  and 
conclusions  based  upon  the  systems  design  and  implementation  re¬ 
view.  The  systems  analysis  points  out  certain  improvements  that 
should  be  made  in  the  systems  themselves,  and  indicates  changes 
that  must  be  made  to  the  procedures  to  permit  a  redesign  of  the 
systems  in  order  to  make  the  systems  more  effective  and  effi¬ 
cient.  Paragraphs  B.  and  C.  of  Part  2  of  this  Chapter  covered 
management  and  policy  improvements,  clarification  and  changes 
that  are  required.  This  paragraph  discusses  required  changes  to 
the  IMM  Manual  that  are  needed  to  make  the  procedures  a  truly 
effective  functional  requirements  statement  that  is  compatible 
with  the  supply  support  concept  and  conceptual  system  require¬ 
ments  reflected  in  this  Report. 

2 .  IMM  Manual 


a .  Organization 

The  IMM  Manual  currently  contains  a  separate  volume 
for  commodity  oriented  consumables  and  one  for  weapon  system 
oriented  consumables.  The  procedures  for  requesting  supply  sup¬ 
port  for  WIMM  items  were  originally  in  an  appendix  in  Volume  II. 
However,  the  procedures  for  SSRs  for  WIMM  items  were  incorporated 
into  Volume  1  for  commodity  oriented  items,  effective  May  1978. 

The  SSR  procedures  for  both  CIMM  and  WIMM  items  are  very  similar 
and  this  appears  to  be  a  very  logical  transfer. 

The  remainder  of  Volume  II  contains  sections  that  are 
extremely  redundant  with  Volume  I.  Other  sections  of  Volume  II 
appear  to  be  redundant  with  procedures  contained  in  other  mili¬ 
tary  standard  system  procedures  manuals.  Volume  II  contains  much 
dated  material.  It  would  appear  that  with  the  successful  merger 
of  the  CIMM  and  WIMM  SSR  procedures  into  one  manual,  the  redun¬ 
dancy  of  the  coverage  in  other  areas  and  the  fact  that  much  of 
the  material  in  Volume  II,  is  outdated,  Volume  II  should  be  con¬ 
sidered  a  prime  candidate  for  a  merger  with  Volume  I.  The  current 
reference  in  the  title  to  commodity  oriented  items  is  now  obso¬ 
lete  since  it  now  contains  SSR  procedures  for  both  CIMM  and  WIMM 
items . 
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A  complete  reorganization  of  Volume  I  should  be  ac¬ 
complished  with  the  merger  of  Volumes  I  and  II.  The  manual  should 
be  made  into  a  true  procedures  manual  that  implements  the  policy, 
objectives  and  intent  of  th^  UoD  directive  for  integrated  mate¬ 
riel  management.  the  manual  for  commodity  oriented  items  was 
orie' naiiy  an  item  management  coding  manual  and  contains  much  of 
its  original  orientation,  organization  and  empha?is.  Much  like 
the  "add  on"  appearance  of  some  of  the  systems  design  of  some  of 
the  SSR  subsystems  that  was  observed  during  the  study,  the  SSR 
Procedures  appear  to  have  been  "added  on"  to  the  procedures  in  the 
original  Item  Management  Coding  Manual  and  called  the  Integrated 
Materiel  Management  Manual. 

Chapter  I  contains  the  introductory  information  that 
should  be  general  enough  in  nature  to  cover  all  the  procedures 
chapters;  however,  it  appears  to  be  oriented  toward  the  Item 
Management  Coding  Procedures  to  the  exclusion  of  the  SSR  Proce¬ 
dures.  The  definitions  and  acronyms  should  be  combined  for  all 
chapters  and  included  in  appendices.  The  policies,  responsibil¬ 
ities,  procedures  and  appendices  should  be  portrayed  in  a  stan¬ 
dard  manner  for  all  procedures  chapters. 

b .  Administration 

A  standard  system  for  administration  and  maintenance 
of  the  manual  should  be  set  up.  It  appears  that  the  IMM  Manual 
established  an  Integrated  Materiel  Management  Committee  (IMMC) 
with  specific  assigned  responsibilities  to  carry  out  the  Item 
Management  Coding  Program  and  to  propose,  review  and  publish 
changes  to  the  manual.  But,  there  is  no  reference  to  the  respon¬ 
sibilities  for  the  SSR  Procedures.  As  a  matter  of  practice,  it 
appears  that  the  Special  Projects  Group  (SPG)  for  Provisioning 
has  responsibility  for  monitoring  the  SSR  Procedures  contained 
in  he  manual,  but  the  responsibilities  are  not  listed  in  the 
manual. 

Although  the  manual  provides  for  numbering  of  formal 
and  interim  changes,  the  DODSSR  Study  Team  had  difficulty  in  keep¬ 
ing  track  of  proposed  and  interim  changes  to  the  manual.  There 
does  not  appear  to  be  any  numbering  system  for  proposed  changes. 
Changes  to  the  IMC  and  SSR  portions  to  the  manual  seem  to  be 
accomplished  using  different  methods  and  organizational  elements. 

It  appears  that  some  SICCs  and  IMMs  are  unilaterally 
making  informal  changes  to  the  procedures  through  interpretation 
and  application  of  data  element  codes  and  definitions  to  apply 
to  problem  conditions  affecting  certain  SSR  submitters  and  re¬ 
ceivers.  Sometimes  these  exceptions  are  then  applied  "across 
the  board”  to  other  activities  or  Components  which  have  traffic 
with  the  activities  that  are  applying  a  special  interpretation. 


The  other  activities  or  Components  are  not  always  aware  of  the 
special  interpretations  or  do  not  agree  with  them.  If  the  prob¬ 
lems  are  serious  enough  to  require  a  special  interpretation  or 
exception,  they  should  be  reported  through  a  formal  problem 
reporting  and  coordination  system  through  the  headquarters  level 
for  resolution,  staffing,  coordination  and  publication  of  an 
interim  change  if  necessary. 

It  is  recommended  that  a  formal  system  be  established 
for  administration  and  maintenance  of  the  IMM  Manual.  The  respon¬ 
sibility  for  administration  and  maintenance  of  the  manual  should 
be  clearly  spelled  out.  A  formal  change,  proposal,  review,  co¬ 
ordination  and  control  process  with  a  standard  numbering  system 
for  formal.  Interim  and  proposed  changes  should  be  established. 
Advance  notice  of  changes  should  be  published  to  permit  systems 
design  and  development  to  be  accomplished  by  a  specific  coordi¬ 
nated  implementation  date. 

3.  SSR  Procedures.  The  changes  recommended  to  the  SSR  Pro¬ 
cedures  (DoDM  4140.26)  are  keyed  to  the  functional  requirements 
statement  and  conceptual  systems  chart  presented  in  Chapter  IV, 
Volume  I,  of  this  Report  and  to  Chapter  4  and  Appendix  E  of  the 
IMM  Manual  itself.  The  recommended  changes  to  the  SSR  Proce¬ 
dures  in  the  IMM  Manual  supplement  the  policy  recommendations  and 
changes  to  the  general  organization  and  administration  of  the  IMM 
Manual  that  were  recommended  in  Sections  C.  and  D.2.  above. 

a.  General  Organization  of  SSR  Procedures.  The  general 
authority,  purpose,  objectives,  scope,  applicability,  responsi¬ 
bilities  and  administrative  statements  pertaining  to  the  manual 
as  a  whole  should  be  in  Chapter  1,  with  specific  references 
applicable  only  to  SSR  processing  contained  in  the  beginning  part 
of  the  SSR  chapter.  All  definitions,  acronyms,  tables,  formats 
and  exhibits  should  be  contained  in  appendices  and  appropriately 
Indexed.  Current  policy  and  procedures  statements  in  Chapter  4 
of  the  IMM  Manual  should  be  revised  to  eliminate  the  redundancy 
between  policy  and  procedures  with  these  policy  statements  per¬ 
taining  to  SSRs  separated  from  the  procedures  and  listed  in  the 
beginning  of  the  chapter.  The  procedures  should  be  removed  from 
Appendix  E  and  placed  in  the  main  body  of  the  SSR  Procedures 
Chapter  and  merged  with  the  procedures  contained  there.  The 
appendices  should  be  limited  to  transaction  entry  instructions, 
data  elements,  codes,  tables,  formats  and  exhibits,  etc.  The 
Intent  is  to  say  a  thing  once,  in  its  proper  place,  in  order  to 
eliminate  the  extensive  redundancy  and  associated  conflicting 
statements  that  are  Inherent  in  the  current  procedures.  Some  of 
the  problems  being  experienced  in  SSR  processing  under  the  cur¬ 
rent  system  are  directly  attributable  to  conflicting  guidance  or 
interpretation  contained  in  different  sections  of  the  procedures. 
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b.  Purpose .  A  purpose  statement  should  be  Included  in 
SSRs.  The  wording  contained  In  Section  C.2.b.  above  Is  recom¬ 
mended  . 


c.  Definition  of  SSR.  The  definition  of  supply  support 
requests  In  Chapter  1  of  the  IMM  Manual  should  be  revised  In 
accordance  with  the  recommendation  In  Section  C.2.a.  above. 

d.  Policy .  The  policy  section  should  be  revised  to 
Include  the  policy  statements  contained  in  DoDI  5100.63  after 
the  policy  recommendations  contained  in  Section  C.  above  have 
been  provided.  DoDI  5100.63  should  then  be  cancelled. 

e.  Scope .  The  statement  of  coverage  (exclusions  and 
Inclusions)  specifying  what  items  and  what  type  of  requirements 
are  covered  should  be  removed  from  the  policy  section  and  placed 
in  this  section.  Any  exceptions  should  be  specifically  stated. 

f.  Applicability.  This  section  should  indicate  that  the 
procedures  apply  to  all  Department  of  Defense  and  Civil  Agencies 
in  requesting  supply  support  for  consumable  items,  and  that  no 
other  procedures  or  formats  are  appropriate.  It  is  recommended 
that  the  Components  apply  the  procedures  within  as  well  as  among 
Components . 

g.  Procedures .  The  procedures  section  should  clearly 
outline  the  responsibilities,  functions  and  tasks  of  SSR  submit¬ 
ters  ( SICCs )  and  receivers  (IMMs)  associated  major  events  involved 
in  the  generation,  transmission,  processing  and  controlling  of 
supply  support  requests.  The  procedures  should  be  keyed  to  the 
logical  order  of  phases  and  events  as  shown  in  the  conceptual 
systems  chart  in  Part  1  of  this  Chapter.  The  detailed  procedures 
should  be  revised  after  a  thorough  review  of  the  IMM  Manual  and 
the  entire  DODSSR  Study  Report.  Key  change  requirements  are 
highlighted  below  for  events  that  are  considered  critical  for 
which  major  problems  were  experienced.  Events  that  are  common 

to  SICCs  and  IMMs  are  discussed  together  here  and  do  not  neces¬ 
sarily  represent  the  order  of  coverage  or  inclusiveness  of  cover¬ 
age  that  should  be  included  in  the  SSR  Procedures  in  the  IMM 
Manual . 


(1)  Generation .  Procedures  and  criteria  for  genera¬ 
tion  of  supply  support  requests  based  upon  results  of  the  policy 
review  recommended  in  Section  C.  above  should  be  included  in  this 
part  of  the  procedures.  This  part  should  relate  to  the  coverage 
of  the  scope  part  and  should  indicate  when  a  request  should  or 
should  not  be  generated.  Coverage  should  include  initial,  change, 
and  delete  actions  for  initial  provisioning,  reprovisioning ,  fol¬ 
low-on  provisioning,  phased  provisioning,  multiple-year  procure¬ 
ments  and  nonprovisioning  in  accordance  with  the  policy  clarifica¬ 
tions  from  the  recommendation  in  Section  C. 
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(  2  )  Method  of  Support/Level  of  Support  Determina¬ 
tions.  The  results  of  the  recommended  policy  review  should  be 
included  under  this  category* 

(3)  Requirements  Forecasting.  This  category  should 
include  the  policy  clarification  on  accumulation  and  roll  up  of 
requirements  recommended  in  Section  C. 

(4)  Funding  of  Requirements.  The  policy  clarifica¬ 
tion  from  Section  C.  should  be  incorporated  into  this  part. 

(5)  Technical  Data.  The  requirements  for  technical 
data  Including  a  clear  definition  of  technical  data  and  when  it 
is  required  should  be  provided.  The  results  of  the  policy  review 
recommendation  should  be  Included  in  this  section.  Transmission 
control  and  monitoring  of  submission  of  technical  data  should  be 
performed  in  accordance  with  Section  D.3.g.(8)  below. 

(6)  Catalog  Data  Screening.  The  failure  of  SICCs 
to  adequately  perform  local  and  DLSC  catalog  screening,  item 
identification  and  item  classification  to  obtain  NSNs  for  part 
numbered  items,  to  pick  up  standard  and  replacement  NSNs  for  non¬ 
standard  and  cancelled  items  is  a  major  cause  of  a  large  number 
of  rejects.  After  completion  of  the  recommended  catalog  review, 
the  SICCs  should  develop  automated  processing  and  control  proce¬ 
dures  to  screen  part  numbered  and  stock  numbered  items  and  pro¬ 
cess  the  replies  prior  to  submission  of  SSRs .  This  should  be 
accomplished  within  30  days  prior  to  submission  of  the  request. 

If  this  is  accomplished,  it  will  reduce  the  number  of  rejections 
currently  being  experienced  because  of  the  failure  to  pick  up  an 
NSN ,  standard  or  replacement  item,  existing  IMM  manager,  or  to 
properly  classify  a  part  number  item  in  its  assigned  class  and 
thus  be  able  to  correctly  associate  it  with  the  appropriate 
potential  IMM.  This  is  an  action  that  can  be  accomplished  under 
the  current  system  and  can  significantly  reduce  the  number  of 
rejects.  If  screening  is  properly  accomplished  by  the  SICC,  it 
would  facilitate  the  screening  and  item  entry  control  procedures 
of  the  IMM.  Screening  of  part  numbers  or  interrogations  of  stock 
numbers  should  still  be  performed  by  the  IMM.  Consideration 
should  be  given  by  the  SICCs  and  IMMs  to  screening  local  files 
particularly  for  NSN  items.  If  the  item  matches  local  files, 

the  SSR  could  be  created  and  forwarded  earlier  by  the  SICC  and 
the  IMM  could  provide  advice  sooner  and  initiate  updates  for 
DLSC  files  at  the  time  of  the  advice  decision.  Probable  and 
possible  matches  received  by  the  IMM  should  be  forwarded  to  Item 
Entry  Control.  Pickups  of  standard,  replacement,  actual  matches 
and  identifications  to  other  IMMs  should  be  processed  and  not 
rejected • 
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(7 )  Validation 


The  analysis  of  the  reject  rates  In  the  quan¬ 
titative  evaluation  and  validation  analysis  indicated  that  too 
many  requests  were  being  rejected  due  to  validation  errors.  This 
is  particularly  so  for  NSN  items  for  which  a  minimum  of  data  ele¬ 
ments  should  be  required  to  process  a  request  for  supply  support. 
This  is  caused  by  a  number  of  reasons.  Some  of  the  SSR  transac¬ 
tions  are  prepared  on  a  manual  basis  and  forwarded  without  being 
subject  to  an  automated  validation  routine.  Data  elements  in 
provisioning  documentation  are  not  always  validated  prior  to 
entry  into  provisioning  files  or  prior  to  preparation  of  the  SSR. 
The  current  procedures  are  subject  to  interpretation  and  differ¬ 
ent  sections  of  the  SSR  Procedures  provide  different  guidance 
for  entry  of  data  elements  in  various  formats. 

The  validation  programs  developed  by  the  Compo¬ 
nents  are  based  upon  different  procedures  and  different  criteria 
for  validation  of  certain  data  elements  or  conditions.  Internal 
and  external  error  codes  vary  among  the  Components  as  do  the  rules 
for  entry  of  valid  and  invalid  records  in  suspense  and  history 
files.  Some  of  the  reject  codes  in  the  procedures  are  too  general 
and  do  not  identify  the  specific  data  elements  in  error  and  are 
not  conducive  to  either  computer  or  manual  processing.  Others 
are  too  specific  and  while  they  may  be  conducive  to  computer  pro¬ 
cessing  they  are  not  conducive  to  manual  processing.  Some  of  the 
reject  codes  did  not  experience  any  usage  during  the  entire  eight 
months  data  collection  period  while  the  frequency  for  others  was 
so  low  as  to  approach  zero.  There  are  so  many  codes  it  is  dif¬ 
ficult  for  the  functional  processor  to  remember  them.  Many  of 
the  rejects  are  caused  by  package  rejects  that  occur  when  a  data 
element  in  the  PDSSR  header  card  is  in  error  and  all  the  line 
item  requests  are  rejected  along  with  the  header  card.  Some  of 
these  rejects  are  for  "mandatory"  data  elements  that  are  not 
even  used  by  the  IMM  in  making  supply  support  determinations. 

This  Report  recommends  a  complete  revision  of 
the  SSR  Procedures,  transactions  and  formats.  A  set  of  standard 
validation  procedures,  criteria  and  codes  should  be  provided  to 
ensure  a  common  interpretation  of  the  requirements  for  entry  of 
control  and  detail  data  elements.  A  convention  should  be  estab¬ 
lished  to  permit  the  identification  of  up  to  five  errors  in  a 
reject  transaction  while  reducing  the  number  of  reject  codes 
currently  being  used.  A  separate  transaction  with  a  separate 
document  identifier  series  should  be  established  to  identify 
validation  rejects  from  action  rejects  and  to  identify  the  spe¬ 
cific  data  elements  in  error. 

The  standard  validation  procedures  should  be 
published  in  the  revised  SSR  Procedures  and  should  be  mandatory 
for  both  SICCs  and  IMMs.  These  procedures  should  specify  the 
hierarchy,  levels,  sequence,  and  ed it /val idat ion  criteria  for 
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control  data  eleaents,  detail  data  eleaents,  error  handling,  and 
file  recording  procedures.  The  aaae  error  codea  should  be  uaad 
Internally  and  externally  to  the  validation  activity. 


Pending  the  revision  of  the  SSR  Procedures  and 
publication  of  the  standard  validation  procedures,  an  lnterla 
change  should  he  published  to  provide  guidance  on  ways  to  relax 
the  validation  in  the  current  aystea  to  reduce  the  Incidence  of 
occurrence  of  those  few  error  conditions  that  are  causing  the 
aajority  of  the  validation  rejects.  Data  eleaents  that  ere 
targeted  for  deletion  in  the  new  procedures  should  be  bypassed 
in  the  validation.  Data  eleaents  that  are  not  critical  to  pro-* 
cessing,  such  as  shelf  life  code  and  special  aaterlal  content 
code  should  not  be  rejected  but  should  be  edited  to  the  appli¬ 
cable  code  indicating  the  absence  of  the  condition,  such  as  the 
code  indicating  that  the  itea  does  not  have  a  shelf  life.  This 
does  not  relieve  the  SICC  of  the  requlreaent  to  ensure  that  con¬ 
tractors  continue  to  enter  indicative  data  eleaents  such  as 
shelf  life  in  provisioning  lists  and  forward  valid  data  to  IMMs 
in  SSRs  . 


( 8 )  Transaission 

The  SSR  Procedures  currently  perait  SSR  advice 
transactions  to  be  forwarded  over  AUTODIN.  Soae  SICCs  and  IMMs 
use  AUTODIN  and  soae  are  using  aail.  Under  the  current  proce¬ 
dures  mail  is  the  standard  aode  being  used  for  both  SSR  transac¬ 
tions  and  technical  data. 

The  quantitative  evaluation  and  the  AUTODIN/ 
TELEFAX  Test  Indicated  that  significant  savings  in  tiae  could  be 
saved  by  electrically  transaltting  both  SSR  tranaactlons  and 
technical  data.  Although  the  TELEPAX  systea  aa  tested  is  not 
considered  appropriate  as  an  ongoing  systea  for  the  transaission 
of  technical  data,  it  did  indicate  that  electrical  transaission 
of  technical  data  is  conceptually  sound  and  that  potential  bene¬ 
fits  can  be  realized  if  a  aore  appropriate  systea  can  be  devel¬ 
oped.  The  evaluation  did  indicate  that  there  were  still  benefits 
to  be  gained  by  sending  all  SSR  transactions  over  AUTODIN  under 
the  current  systea  accoapanied  by  an  itea  naae  card  for  all  part 
numbered  iteas,  with  technical  data  to  be  forwarded  by  aail.  The 
technical  data  should  be  marked  with  control  data  and  mailed  to 
the  IMM  as  soon  as  the  item  is  coded  for  integrated  aanageaent. 

The  lmproveaent  in  control,  savings  in  trans¬ 
mitting,  processing  and  wait  tiae,  reductions  in  the  number  of 
followups  and  reaubmlsslons ,  and  improved  audit  trail  indicate 
that  this  alternative  ahould  be  pursued  immediately,  with  a 
study  to  follow  to  deteralne  the  feasibility  of  electrical  trans¬ 
mission  of  technical  data  from  technical  library  to  technical 
library.  The  current  procedures  should  also  be  modified  to 
establish  a  convention  for  the  IMM  to  followup  when  technical 
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data  Is  not  received.  The  SICC  should  establish  controls  to 
ensure  that  technical  data  Is  forwarded  and  the  IMM  should  moni¬ 
tor  and  measure  the  Incidence  of  receipt  of  technical  data. 

Under  this  concept  the  SICC  should  enter  the  technical  data  in 
the  technical  library  as  soon  as  possible.  The  technical  data, 
preferably  In  aperture  card  form,  should  be  marked  with  control 
data  and  mailed  as  soon  as  possible.  The  SICC  as  the  technical 
manager  of  the  item  should  retain  a  copy  of  the  technical  data 
in  the  technical  library  and  the  IMM  should  be  required  to  re¬ 
turn  the  technical  data  if  supply  support  for  an  item  is  rejected. 

The  IMM  should  not  reject  an  item  for  lack  of  tech¬ 
nical  data  unless  there  is  Insufficient  data  to  identify  an  item 
for  stock  numbering  purposes.  Copies  of  reports  measuring  the 
performance  of  SICCs  in  the  submission  of  technical  data  should 
be  provided  to  the  SICCs  by  the  IMMs.  Summary  copies  of  the 
technical  data  management  reports  should  be  provided  to  Compo¬ 
nent  headquarters  levels  for  use  in  monitoring  the  performance 
of  activities  in  acquiring  and  providing  technical  data. 

h .  Transaction  Types 

Current  procedures  provide  for  three  basic  types  of 
SSR  transactions;  program  data,  line  item  supply  support  requests 
and  advice.  These  transaction  types  are  further  subdivided  into 
specific  transactions  through  the  use  of  Document  Identifier  Codes 
(DICs)  and  transaction  codes  called  Action  Taken  Codes  (ATCs). 
There  are  70  different  ATCs  in  the  manual  to  identify  different 
types  of  transactions  and/or  conditions.  Although  the  advice 
transactions  are  subdivided  by  DIC,  the  ATC  must  also  be  used  in 
conjunction  with  the  DIC  to  identify  the  transaction. 

Request  transactions  consist  of  a  package  of  trans¬ 
actions  which  is  a  combination  of  program  data  card  that  is  a 
header  for  the  entire  package,  a  line  item  request  transaction 
which  may  contain  one  or  two  cards  and  anywhere  from  one  to  three 
different  types  of  catalog  cards.  The  cards  must  be  related  to 
one  another  through  control  data.  If  the  cards  are  not  asso¬ 
ciated  properly  a  line  item  package  or  an  entire  provisioning 
package  may  be  rejected. 

The  study  group  received  complaints  about  the  ex¬ 
cessive  number  of  rejects  being  received.  Functional  personnel 
at  operating  activities  complained  that  there  were  too  many 
packages,  too  many  different  types  of  cards  per  packages  and  too 
many  ATCs.  It  was  felt  that  some  of  the  ATCs  were  too  general 
by  systems  design  activities  and  both  too  general  and  too  specif¬ 
ic  by  operating  activities.  Operating  activities  said  that  since 
the  ATCs  did  not  have  any  specific  groupings  and  some  of  the 
definitions  were  vague  or  conflicting  they  had  a  difficult  time 
distinguishing  between  a  validation  reject  and  an  action  reject. 
They  said  they  were  not  sure  when  an  item  was  accepted,  when  it 
was  accepted  conditionally  and  when  it  was  rejected. 
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As  discussed  In  Volumes  II  and  III,  the  study  team 
reviewed  all  the  transaction  types  by  DIC  and  ATC  and  categorized 
the  transactions  into  basic  event  types  and  further  subcategorized 
reject  transactions  into  reject  categories  to  evaluate  the  per¬ 
formance  of  the  system.  Accept  and  reject  rates  were  computed 
by  category,  subcategory  and  individual  DIC  and  ATC.  Times  to 
accomplish  different  events  based  on  transaction  types  were  de¬ 
rived  and  time  to  complete  an  entire  SSR  cycle  from  beginning  to 
end  were  computed.  Transactions  were  analyzed  individually  and 
in  relation  to  other  types  of  transactions. 

Transactions  are  the  basic  method  of  communication 
of  events  whether  it  be  in  a  business  system  or  in  a  logistics 
system.  Through  the  use  of  transaction  analysis,  the  study  group 
confirmed  the  problem  that  had  been  reported  to  the  study  team. 

We  found  that  the  package  system  using  the  program  data  card  as 
a  header,  with  associated  line  item  packages  and  catalog  cards 
were  causing  a  large  number  of  the  validation  errors.  We  also 
found  that  most  of  the  data  elements  in  the  program  data  card 
were  either  not  used  or  were  too  inconsistently  entered  or  not 
meaningful  to  be  used.  The  catalog  cards  usually  contained  more 
control  data  elements  to  link  the  cards  than  detail  data  ele¬ 
ments  that  were  being  used.  In  addition,  some  of  the  catalog 
cards  were  being  used  such  a  small  portion  of  the  time  that  their 
use  at  all  was  questionable. 

We  found  that  a  small  number  of  transaction  codes 
were  involved  in  a  large  frequency  of  cases.  Some  of  the  codes 
either  experienced  no  usage  at  all  during  the  evaluation  period 
or  were  so  infrequently  used  as  to  round  to  zero.  We  had  dif¬ 
ficulty  in  placing  some  of  the  transactions  into  categories  our¬ 
selves  using  the  ATCs.  We  found  that  after  receipt  the  packages 
were  generally  processed  on  a  transaction  basis  anyway  and  that 
most  of  the  header  data  was  not  even  being  used.  Transactions 
that  were  completed,  were  sometimes  held  up  for  an  entire  pack¬ 
age  to  be  completed. 

As  a  result  of  this  evaluation  it  was  decided  that 
the  procedures  should  be  completely  revised  to  better  relate 
transactions  to  event  types  and  that  the  package  concept  should 
be  eliminated  to  the  extent  possible  and  the  transaction  iden¬ 
tification  system  using  DIC  and  ATC  should  be  completely  over¬ 
hauled.  We  decided  to  use  a  separate  document  identifier  code 
to  identify  basic  transaction  types.  The  validation  reject  codes 
should  be  abolished  entirely  and  a  convention  established  to 
identify  up  to  five  data  element  errors  using  a  data  element 
number  identification  technique.  The  ATCs  for  other  transactions 
should  also  be  totally  revised  to  assign  new  transaction  codes 
called  advice  codes  to  further  identify  the  transaction  type. 

The  codes  should  be  mnemonic  and  should  be  grouped  together  so 
that  all  codes  in  a  group  are  applied  to  the  same  category  of 
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advice  transactions  such  as  accept  or  offer  or  reject.  The  num¬ 
ber  of  transaction  types  and  codes  should  be  kept  to  a  minimum  and 
conditions  with  no  occurrence  should  be  eliminated.  The  specific 
types  of  transactions  are  shown  below. 

( 1 )  Request  Transactions 

Currently  there  are  eleven  different  document 
Identifier  codes  (DICs)  that  can  be  used  to  request  supply  sup¬ 
port.  Separate  DICs  are  used  for  program  and  line  item  requests 
for  CIMM  and  WIMM  items.  The  data  elements  in  the  transactions 
are  almost  Identical  between  the  CIMM  and  WIMM  transactions. 
Processing  procedures  are  very  similar  between  CIMM  and  WIMM. 

Where  there  is  a  difference,  the  WIMM  processing  is  less  restric¬ 
tive  and  really  considers  very  few  of  the  data  elements  in  the 
transactions.  These  transactions  can  be  easily  combined  and  the 
number  of  transaction  types  for  CIMM  and  WIMM  line  item  requests 
can  be  reduced  from  six  to  three.  We  found  that  many  of  the  re¬ 
quest  transactions  that  were  being  sent  to  WIMMs  contained  CIMM 
document  identifier  codes  anyway  that  were  being  processed  by  the 
WIMMs  just  as  if  the  request  had  contained  the  proper  code. 

A  separate  Type  Change  Code  (TCC)  is  used  to 
designate  both  changes  to  SSRs  and  to  designate  provisioning 
and  nonprovisioning  SSRs.  The  use  of  the  provisioning/nonpro¬ 
visioning  distinction  in  a  Type  of  Change  Code  is  inconsistent. 
Also  there  is  no  necessity  to  distinguish  between  provisioning 
and  nonprovisioning  SSRs.  They  should  be  treated  the  same.  The 
use  of  the  TCC  to  designate  provisioning  and  nonprovisioning 
should  be  eliminated  and  the  type  of  change  should  be  designated 
by  the  Provisioning  Line  Item  Sequence  Number  (PLISN). 

There  are  very  few  data  elements  in  the  program 
data  cards  that  are  being  used  by  IMMs.  The  principal  data  ele¬ 
ments  being  used  are  the  date  that  repair  parts  are  required  and 
the  code  indicating  the  percent  of  end  items  to  be  deployed  east 
of  the  Mississippi  River.  The  program  data  currently  being  used 
can  be  Incorporated  into  the  line  item  request  cards  and  the  pro¬ 
gram  data  cards  can  be  eliminated  at  a  net  savings  of  two  trans¬ 
action  types . 
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Currently  the  IMM  is  determining  an  active  from 
an  inactive  NSN  by  looking  at  the  presence  or  absence  of  certain 
data  elements  in  NSN  request  cards*  This  has  caused  a  large  number 
of  rejects  when  data  for  an  active  NSN  has  been  entered  because 
it  has  been  available,  but  was  not  needed  for  an  active  NSN.  It 
is  easier  for  the  automated  processing  routines  to  enter  data  con¬ 
sistently  in  like  transactions  whenever  possible.  The  IMM  can 
obtain  any  additional  data  needed  for  an  inactive  NSN  through 
Interrogation  of  DLSC  files.  The  condition  distinction  should 
be  eliminated. 


The  elimination  of  the  CIMM/WIMM  distinction, 
and  the  distinction  between  active  and  inactive  NSNs  plus  the 
merging  of  program  and  catalog  data  with  the  basic  line  item 
request  will  reduce  the  number  of  transctlons  from  eleven  to 
three  requests  for  integrated  materiel  managed  items;  one  each 
for  NSN,  part  number  and  PSCN  items.  Perhaps  more  importantly, 
each  request  can  be  processed  as  an  individual  line  item,  since 
the  basic  program  package  and  LISSR  package  distinction  will  be 
eliminated.  This  will  eliminate  the  large  number  of  package 
errors  that  are  occurring  and  speed  up  processing  since  valid 
transactions  will  not  be  rejected  along  with  invalid  transac¬ 
tions  and  completed  transactions  will  not  be  delayed  pending  the 
completion  of  other  transactions. 


Accei 


Transactions 


The  transactions  generally  classified  as  line 
item  advice  (LIAC)  document  identifier  codes  CXI  to  CX4  should 
be  placed  in  specific  transaction  categories  that  reflect  the 
events  that  they  represent.  These  transactions  are  usually  sub¬ 
divided  anyway  through  the  use  of  action  taken  codes. 


The  accept  category  should  contain  a  number  of 
transactions  that  are  currently  classified  as  rejects  or  offers 
today.  A  separate  document  identifier  code  should  be  assigned 
to  indicate  an  acceptance  of  an  SSR.  This  transaction  category 
should  include  the  following  four  conditions: 


(a)  Accept  of  Item  Requested.  This  includes 
the  acceptance  of  the  exact  NSN  or  part  number  requested.  If  a 
new  support  date  is  generated  it  should  be  provided  in  the  trans¬ 
action  along  with  the  AAC  to  indicate  the  method  of  support.  If 
it  was  s  part  number  or  PSCN  that  was  requested  an  NSN  will  be 
provided  in  the  transaction  when  available.  Pickups  of  actual 
or  exact  matches  should  be  included  in  this  category  rather  than 
being  rejected. 


(b)  Accept  of  Standard/Replaced  Item.  This 
category  should  contain  acceptance  of  standard  or  replacement 
items  that  are  picked  up  by  the  IMM  during  catalog/IEC  screening. 
In  addition  to  the  new  NSN,  the  transaction  should  provide  the 
standardisation  code  and  phrase  code,  AAC  and  may  contain  a  new 
support  date. 
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(c)  Accept  of  Substitute  Items 


This  category  Includes  NSNs  picked  up  as  a 
result  of  DLSC  Screening  or  Item  Entry  Control  Review.  It  in¬ 
cludes  possible,  probable  or  in-house  matches  that  have  been  pro¬ 
cessed  through  Item  Entry  Control  and  for  which  it  has  been  deter¬ 
mined  that  the  reference  number  requested  can  be  added  as  a  pri¬ 
mary  reference  number.  Additional  data  includes  standardization 
code,  phrase  code,  AAC  and  may  contain  a  new  support  date. 

This  is  a  conditional  acceptance.  Support 
will  be  provided  as  indicated  in  the  accept  transaction,  unless  a 
reply  transaction  is  sent  by  the  SI CC  indicating  nonconcurrence 
with  the  substitute  item,  and  verifying  that  the  item  requested 
is  required. 

( d )  Acceptance  with  Item  Identifier  Change 

Corrections  to  FSCM  and/or  manufacturer's 
reference  numbers  are  included  in  this  category.  These  include 
reformatting  of  part  numbers  ( dashes /slashes /spaces )  and  correc¬ 
tion  of  FSCMs  using  DLSC  reference  tools,  correction  of  part 
numbers  using  manufacturer's  catalogs  and  clarification  from 
contractors  that  are  made  during  Item  Entry  Control.  The  AAC, 
standardization  code,  NSN,  support  date  and  corrected  FSCM/Refer- 
ence  Number  are  included  in  this  transaction. 

This  is  a  conditional  acceptance.  The  sup¬ 
port  will  be  provided  as  indicated  in  the  accept  transaction 
unless  a  reply  transaction  is  sent  by  the  SICC  indicating  non¬ 
concurrence  with  the  change  and  providing  the  corrected  data  for 
the  item. 

This  transaction  was  developed  because  of 
the  request  by  some  of  the  SICCs  and  DLA's  concurrence  with  the 
request  to  correct  FSCMs  and  part  numbers.  The  DODSSR  Study  Team 
provides  this  transaction  as  a  convention  to  accommodate  this 
situation.  Although  the  study  team  recognizes  the  Incidence  of 
this  problem,  it  is  felt  that  the  basic  responsibility  to  provide 
accurate  item  Identifier  information  lies  with  the  provisioning 
activity.  The  provisioning  activity  should  perform  both  an 
automated  validation  of  provisioning  data  supplied  by  the  con¬ 
tractor,  and  a  manual  quality  control  procedure  to  validate  and 
verify  the  accuracy  of  the  entries  on  the  provlsonlng  list.  A 
combination  of  contractor  training  and  quality  control  by  the 
provisioning  activity  is  recommended  to  correct  the  underlying 
problem.  The  DODSSR  Study  Team  has  no  statistics  or  other 
research  to  render  an  opinion  on  the  relative  capability  of  an 
IMM  to  accurately  make  changes  or  corrections  to  manufacturer's 
identifying  information  that  is  provided  to  the  IMM  by  a  SICC 
via  the  SSR. 
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(3)  Offer  Transactions.  Offer  transactions 
should  include  offers  of  part  numbered  items  and  offers  of  stock 
numbered  items  where  the  requested  part  number  can  be  added  only 
as  an  advisory  reference  number  to  the  offered  stock  number.  The 
offer  transaction  should  include  as  much  information  as  possible 
from  the  DLA  Form  546  ( Standard /A1 ternate  Item  Referral)  to  per¬ 
mit  the  offer  to  be  communicated  by  AUTODIN  and  to  preclude  the 
necessity  of  matching  the  transaction  sent  by  AUTODIN  with  the 
manual  form  as  is  the  case  today.  Offers  will  require  a  reply 

by  the  SICC  for  the  IMM  to  continue  processing.  In  lieu,  of  a 
rejection  for  lack  of  response  to  an  offer,  the  IMM  should  fol¬ 
lowup  for  the  reply  to  the  offer. 

(4)  Reply  Transactions.  The  reply  category 
should  include  three  types  of  replies.  The  reply  transaction 
should  be  sent  from  the  SICC  to  the  IMM  to  reply  to  a  conditional 
accept  or  offer  transaction. 

(a)  Reply  to  Acce pt-Subs t i tute .  The  SICC 
should  send  a  reply  to  the  IMM  when  the  SICC  does  not  concur 
with  the  substitute  item  that  the  IMM  intends  to  support.  The 
reply  should  be  sent  within  30  days  of  the  transaction  date  of 
the  accept  transaction  and  should  contain  a  code  indicating  that 
the  IMM  does  not  agree  with  the  substitute  and  requests  support 
on  the  original  item  requested. 

( b)  Reply  to  Accept-Item  Identifier  Change. 
The  SICC  should  send  this  reply  if  there  is  disagreement  with  the 
correction  to  the  FSCM/ Re f erence  Number  by  the  IMM.  The  reply 
should  indicate  the  correct  item  identifying  number  for  the  item 
for  which  support  is  being  requested.  The  reply  should  be  sent 
within  30  days  of  the  date  of  the  conditional  accept  transaction. 

(c)  Reply  to  Offer.  The  offer  transac¬ 
tions  will  require  a  mandatory  response  indicating  acceptance  or 
rejection  of  the  offer.  The  reply  should  be  sent  within  30  days 
of  the  date  of  the  offer  transaction.  The  transaction  should 
contain  two  transaction  or  advice  codes,  one  to  indicate  accep¬ 
tance  and  one  to  indicate  that  the  offer  is  not  accepted  and 
that  support  is  requested  on  the  original  item. 

(5)  Followup  Transaction.  The  new  followup 
transaction  permits  both  the  SICC  and  the  IMM  to  followup  for 
information.  The  four  categories  of  followups  are  as  follows: 

(a)  Initial  Advice.  The  SICC  may  send  a 
followup  for  initial  advice  20  days  for  an  NSN  request  or  35  days 
for  a  part  number  request  after  the  date  of  transaction  of  the 
request.  This  presumes  that  the  requests  are  submitted  by  AUTODIN 
and  that  the  requests  are  forwarded  Immediately  after  creation 
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of  the  request  transaction.  No  wait  time  Is  allowed  for  matching 
up  with  technical  data,  since  the  technical  data  should  be  for¬ 
warded  separately,  and  may  have  already  been  forwarded  prior  to 
the  creation  of  the  SSR.  A  transaction  code  will  indicate  that 
initial  advice  is  being  requested.  Additional  followups  may  be 
sent  out  if  a  response  has  not  been  received  within  15  days  of 
the  transaction  date  of  the  previous  followup. 

(b)  Final  Advice/NSN  Advice.  This  follow¬ 
up  may  be  sent  out  65  days  after  the  date  of  the  initial  request 
transaction  or  35  days  after  the  receipt  of  initial  advice  which¬ 
ever  is  sooner.  The  transaction  code  in  ‘he  followup  will  indi¬ 
cate  that  the  followup  is  for  final  NSN  advice.  Additional 
followups  may  be  sent  if  a  response  has  not  been  received  within 
15  days  of  the  transaction  date  of  the  previous  followup. 

(c)  Technical  Data.  This  transaction  was 
created  to  permit  the  IMM  to  followup  on  the  SICC  for  technical 
data  when  the  Document  Availability  Code  indicates  technical  data 
is  available  but  it  has  not  been  provided.  Lack  of  supplementary 
technical  data  will  not  be  a  cause  for  rejection  of  an  SSR  unless 
the  minimum  technical  data  elements  required  for  stock  numbering 
an  item  have  not  been  received.  The  IMM  may  followup  for  supple¬ 
mentary  technical  data  if  it  has  not  been  received  within  30  days 
of  the  transaction  date  of  the  request  transaction.  The  IMM  may 
then  followup  in  15-day  intervals  if  technical  data  or  a  reply 
indicating  technical  data  cannot  be  supplied  is  not  received 
within  15  days  of  the  original  followup  transaction  date. 

(d)  Offer  Reply.  The  IMM  will  no  longer 
automatically  reject  support  for  failure  to  receive  a  reply  to 
an  offer  within  the  prescribed  timeframes.  Instead,  the  IMM 
will  followup  on  the  SICC  for  the  reply  to  the  offer.  The  IMM 
may  followup  on  the  SICC  after  30  days  of  the  transaction  date 
of  the  original  offer  and  in  15-day  intervals  after  the  first 
followup . 


(6)  Response  to  Followup.  The  response  cate¬ 
gory  should  provide  for  a  response  to  each  of  the  followup  cate¬ 
gories.  The  initial  response  to  a  followup  may  provide  a  status 
reply  Indicating  that  the  request  or  followup  transaction  is  in 
process  and  a  reply  will  be  forwarded  within  15  days  or  may  con¬ 
tain  advice  that  directly  responds  to  the  followup  and  is  recorded 
in  the  suspense  files. 


( a )  Response  to  Followup  for  Initial 
Advice .  If  initial  advice  is  not  recorded  in  the  suspense  file 
and  has  not  been  forwarded,  the  IMM  may  send  advice  indicating 
that  the  request  is  in  process  and  that  advice  will  be  provided 
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within  15  days.  If  initial  advice  haa  been  provided,  the  advice 
will  be  provided  from  the  suspense  file.  If  the  advice  was  an 
accept,  a  complete  accept  advice  will  be  sent,  if  the  advice  was 
an  offer,  complete  offer  advice  will  be  sent.  The  same  holds 
true  for  reject  and  passing  action  advice. 

( b)  Response  to  Followup  for  Final/NSN 
Advice .  The  response  to  the  final/NSN  advice  should  provide  the 
advice  requested  if  it  is  in  the  suspense  file.  If  only  initial 
advice  has  been  provided,  the  IMM  should  provide  advice  indicat¬ 
ing  that  the  final/NSN  advice  is  in  process  and  will  be  provided 
in  15  days.  The  initial  advice  should  not  be  provided  unless 
both  initial  and  final  advice  were  provided  at  the  same  time. 

( c )  Response  to  Followup  for  Technical 
Data .  The  SICC  should  forward  the  technical  data  within  15  days 
of  the  transaction  date  of  the  followup.  If  the  technical  data 
is  not  available  the  response  should  indicate  that  the  technical 
data  is  not  available  and  can  not  be  provided.  If  the  SICC  is 
in  the  process  of  obtaining  the  technical  date,  the  SICC  should 
provide  status  indicating  that  the  SICC  is  in  the  process  of 
obtaining  the  technical  data  and  the  approximate  date  when  the 
technical  data  will  be  provided. 

( d )  Response  to  Followup  for  Reply  to 
Offer .  The  SICC  should  respond  to  the  followup  by  sending  a 
reply  to  offer  transaction.  If  the  reply  is  in  process,  the 
SICC  should  send  a  response  providing  status  indicating  that  a 
reply  is  in  process  and  an  approximate  date  when  the  reply  to 
offer  will  be  provided. 

(7)  Passing  Action.  Currently,  when  an  IMM 
through  DLSC  screening  or  Item  Entry  Control  actions  finds  that 
an  item  has  been  placed  in  an  FSC  for  which  another  activity  is 
the  IMM  or  for  which  another  activity  is  already  recorded  and 
the  IMM  for  the  Item,  the  IMM  rejects  the  request  back  to  the 
SICC.  Since  the  SICC  has  already  made  the  item  management 
coding  determination  that  the  item  should  be  assigned  to  inte¬ 
grated  management,  It  only  delays  the  processing  for  an  item  for 
it  to  be  rejected  back  to  the  SICC  to  prepare  another  request  to 
be  sent  to  the  correct  manager.  Requisitions  for  items  are 
routed  to  the  correct  manager  with  status  information  provided 
to  the  requestor.  There  does  not  appear  to  be  any  reason  why 
the  IMM  cannot  reroute  or  pass  the  original  request  to  the 
correct  IMM  with  passing  information  to  the  requestor  so  that 
the  requestor  can  update  his  suspense  files.  The  SICC  should 
send  any  followups  to  the  new  destination  with  the  followup  pre¬ 
dicated  upon  the  transaction  date  of  the  passing  action  rather 
than  the  transaction  date  of  the  original  request. 
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Currently  all  types  of  rejects  are  lumped  into 
the  same  transaction  category  (CXI  Advice)  as  accepts,  offers, 
and  rejects.  It  is  not  always  easy  to  ascertain  whether  the 
advice  is  an  accept  or  whether  the  advice  is  a  reject.  The  indi¬ 
vidual  advice  code  (ATC)  and  definition  must  be  reviewed  to  deter¬ 
mine  if  it  is  a  reject  and  the  type  of  reject. 

There  are  about  57  ATCs  that  can  be  used  to  pro¬ 
vide  reject  advice  under  the  current  system.  The  codes  do  not 
indicate  whether  the  reject  is  a  validation  reject,  support  re¬ 
ject  or  a  reject  for  technical  considerations.  Some  reject  codes 
are  too  general  and  do  not  indicate  the  specific  data  element  or 
condition  that  is  in  error.  Others  are  very  definitive,  but 
occur  so  infrequently  as  to  question  whether  they  warrant  the 
assignment  of  a  specific  code. 

In  summary,  the  codes  should  be  grouped  to  indi¬ 
cate  whether  the  reject  is  a  validation  reject  or  whether  it  is 
a  condition  reject  and  what  the  condition  is  (support,  technical 
match/duplication  or  other  reason)  .  The  number  of  codes  can  be 
reduced,  yet  made  more  definitive.  This  can  be  done  by  using  a 
separate  technique  for  validation  rejects  and  by  categorizing 
action  rejects,  merging  duplicate  conditions  and  eliminating 
conditions  that  do  not  occur  at  all  or  occur  extremely  infre¬ 
quently  . 

(a)  Validation  Reject.  A  set  of  standard  vali¬ 
dation  procedures  and  criteria  should  be  published  in  the  IMM 
Manual.  The  reject  codes  should  permit  the  identification  of  up 
to  five  errors  at  a  time  and  the  same  error  codes  should  be  used 
internally  and  externally  to  preclude  confusion  on  the  part  of 
functional  workers.  The  validation  reject  should  have  a  trans¬ 
action  code  indicating  that  it  is  a  validation  reject.  The  spe¬ 
cific  data  elements  in  error  should  then  be  identified  using  a 
data  element  number  (DEN)  or  data  record  number  (DRN).  This 
technique  has  a  precedent  in  that  it  is  already  used  by  DLSC  to 
communicate  validation  errors  in  this  fashion  to  activities  that 
send  transactions  to  DLSC.  The  transaction  code  identifies  that 
it  is  a  validation  reject  and  the  data  element  number  indicates 
the  data  element  in  error.  The  definition  of  the  data  element 
and  the  data  element  codes  are  maintained  as  a  part  of  data  ele¬ 
ments  maintenance. 


(b)  Technical  Reject.  This  category  should 
contain  items  that  are  rejected  for  technical  reasons  such  as  an 
invalid  FSCM  that  cannot  be  corrected,  invalid  part  number  that 
cannot  be  corrected,  nondefinitive  unit  of  issue.  The  first 
position  should  identify  the  particular  error  condition. 


(c)  Support  Reject .  These  Items  are  rejected 

for  support  because  they  do  not  fall  within  the  purview  of  the 
IMM  and  cannot  be  rerouted  to  another  manager.  Included  within 
this  category  are  such  conditions  as  items  that  should  be  coded 
for  retention  or  are  in  a  class  of  Items  such  as  fuels  or  medical 

material  that  do  not  come  under  the  SSR  Procedures  . 

(d)  Match/Duplicate  Reject.  This  category  con¬ 
tains  items  that  are  rejected  because  they  do  not  match  up  -to  a 
previous  record  on  the  suspense  file  such  as  change  transactions 
or  the  transactions  are  complete  80-character  duplicates  or  con¬ 
trol  element  duplicates. 

(e)  Other .  Other  rejects  are  those  for  which 

no  other  reject  category  applies  or  "in  the  clear"  explanatory 
information  is  required  to  explain  the  reject  condition.  A 
review  of  the  quantitative  evaluation  and  field  research  indi¬ 
cated  that  ATC  36,  Other,  under  the  current  system,  was  being  used 

in  lieu  of  offers  or  when  other  reject  codes  could  have  been  used. 

This  transaction  should  be  revised  to  permit  the  exception  data 

to  be  entered  that  is  now  being  provided  on  the  manual  Standard/ 
Alternate  Item  Re f e r ra 1 / Re jec t  Notification  form.  A  large  field 
should  be  provided  in  addition  to  certain  standard  codified  in¬ 
formation  to  permit  explanatory  remarks  to  be  sent  over  AUTODIN 
instead  of  being  forwarded  by  mail  which  requires  the  matching 
up  with  the  transaction  that  is  currently  being  sent  over  AUTODIN. 

i  .  Data  Elements  .  Only  the  data  .elements  that  are 
required  for  each  of  the  transaction  types  should  be  retained. 

Data  elements  that  are  not  being  used  today  or  not  required 
should  be  deleted.  Data  elements  that  have  a  marginal  utility 
should  be  considered  for  deletion.  Additional  data  elements 
needed  for  a  particular  transaction  type  should  be  added. 

j .  Forma  t  s 


The  formats  should  be  revised  to  suit  the  new  trans¬ 
action  types  after  the  deletion  of  unrequired  data  elements  and 
addition  of  new  required  data  elements.  The  data  elements  should 
be  rearranged  into  a  more  logical  order.  Like  data  elements  such 
as  control  data  elements,  transaction  identifier  codes,  item 
identifier  data  elements  and  catalog  and  technical  data  elements 
should  be  grouped  together  in  a  logical  sequence  with  due  con¬ 
sideration  for  standard  conventions  for  the  positioning  of  part¬ 
icular  data  elements. 

As  many  formats  should  be  eliminated  as  possible  to 
simplify  the  process  for  requesting  and  obtaining  supply  support. 
The  package  concept  should  be  eliminated  and  those  data  elements 
absolutely  required  should  be  merged  into  the  line  item  request 
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transactions.  The  separate  program  and  catalog  data  cards  should 
then  be  deleted  to  eliminate  the  package  and  card  combination 
rejects  that  are  attributable  to  the  extra  cards.  The  goal  should 
be  a  single  card  format  for  each  transaction  whenever  possible. 
Whenever  more  than  one  card  is  required,  the  additional  cards 
should  be  identified  using  a  card  number. 

k.  Controls  .  Controls  should  be  maintained  by  both  the 
SICC  and  IMM  to  ensure  accurate  and  timely  generation,  submission 
and  processing  of  SSR  transactions.  Control  of  SSRs  should  be 
maintained  from  the  initial  generation  of  the  first  request  for 
a  line  item  through  all  subsequent  changes  or  references  to  the 
initial  or  change  transactions  to  the  completion  of  the  final 
action  on  the  same  provisioning  control  code  for  the  same  sub¬ 
mitting  (SICC)  activity. 

( 1 )  Standard  Control  Number 


The  use  of  a  standard  control  number  is  the  key 
to  proper  control  of  SSR  transactions  by  the  SICC  and  IMM.  The 
standard  control  number  or  document  number  should  consist  of  the 
control  elements  such  as  activity  codes,  provisioning  control 
code,  provisioning  line  item  sequence  number,  and  date  of  request. 
The  document  number  should  designate  the  overall  control  field 
and  should  consist  of  the  control  elements  as  subfields  grouped 
together  in  a  logical  order  to  facilitate  a  common  or  universal 
technique  for  accessing,  storing,  retrieving,  sequencing,  pro¬ 
cessing,  controlling  and  communication  of  SSR  transactions  within, 
between  and  among  systems  and  activities. 

The  control  number  should  not  be  duplicated  for 
the  same  or  different  items  of  supply  for  the  same  SICC  activity 
for  the  same  provisioning  project  (PCC).  The  PCC  and  PLISN  are 
the  two  key  subfields  in  the  document  number.  The  PLISN  should 
be  used  as  the  serial  number  portion  of  the  document  number 
because  when  coupled  with  the  PCC  and  SICC  activity  code  it  pro¬ 
vides  a  unique  audit  trail  for  clarifying  problems  on  supply 
support  requests  and  preventing  the  creation  and  processing  of 
duplicate  transactions.  The  use  of  the  unique  PCC  and  PLISN 
also  permits  the  maintenance  of  status  on  an  individual  item  in 
a  provisioning  project,  the  status  of  provisioning  and  supply 
support  for  the  entire  provisioning  project,  and  the  rollup  or 
accumulation  of  requr i r ement s  for  the  same  item  of  supply. 

(2)  Package/Transaction  Control.  Supply  support 
requests  should  be  processed  by  the  IMM  on  an  individual  trans¬ 
action  basis  (instead  of  being  processed  on  a  package  basis). 

The  individual  transactions  should  be  matched  against  SSR 
suspenee/history  files  to  match  to  related  transactions  and  to 
prevent  duplicates  within  a  provisioning  control  project  (PCC). 
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A  given  SSR  transaction  should  not  be  delayed  pending  the  comple¬ 
tion  of  another  SSR  in  the  same  provisioning  list  simply  because 
they  were  submitted,  received  together  and  processed  in  the  same 
cycle. 

( 3 )  Suspense/Hla tory  Plle(s) 

A  suspense/history  file  should  be  maintained  on 
all  SSR  transactions.  The  SICC  should  maintain  a  file  of  all 
transactions  submitted  and  received  and  the  IHM  should  maintain 
a  file  of  all  SSR  transactions  submitted  and  received.  The  file 
should  contain  a  complete  audit  trail  of  all  SSR  transaction 
types  pertaining  to  the  same  control  number.  This  file  should 
be  maintained  for  a  period  of  two  years  from  the  completion  of 
the  last  action  for  the  same  activity/PCC  combination. 

Tt'e  date  of  request  should  be  used  for  control 
purposes  in  combination  with  a  date  of  transaction  to  relate  all 
subsequent  change  and  advice  transactions  to  the  initial  request 
for  the  same  item  of  supply  for  the  same  provisioning  project. 

This  file  should  be  used  to  match  incoming  trans¬ 
actions  to  prevent  duplicates,  to  generate  Internal  and  external 
followups,  to  provide  responses  to  followups  and  internal  inquiries, 
to  provide  listings  and  reports  for  operational  control  of  SSR 
processing  and  management  reports  to  measure  the  effectiveness  and 
efficiency  of  the  system. 

The  file  should  be  used  to  provide  status  on  an 
individual  line  item  and  should  be  used  to  provide  complete  status 
of  provisioning  and  supply  support  on  a  provisioning  project  or 
end  item  using  the  PCC  and  systems  designator,  respectively. 

A  record  of  the  number  of  followups  and  rejects 
should  be  maintained  by  the  SICC  and  the  IMM.  After  the  second 
followup  for  the  same  transaction,  a  local  exception  action  should 
be  generated  for  manual  review  to  determine  what  the  problem  is 
and  to  expedite  the  final  resolution  and  completion  of  the  indi¬ 
vidual  action.  Internal  and  external  followups  should  be  gener¬ 
ated  for  overdue  actions  based  upon  the  allowed  times  for  comple¬ 
tion  of  individual  transactions  and  generation  of  followups. 

All  incoming  and  outgoing  transactions  should 
be  generated  as  a  result  of  file  maintenance  to  this  file.  That 
is  a  transaction  should  not  be  transmitted  to  an  internal  func¬ 
tional  organization  or  external  activity  without  having  been 
first  validated  and  preposted  to  this  file.  Outgoing  transac¬ 
tions  to  external  activities  should  be  immediately  routed  to 
AUTODIN  operations  after  ■  atlcn. 
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1.  Allowed  Times 


Although  the  SSR  Procedures  contain  numerous  times 
for  the  accomplishment  of  certain  events  and  times  that  must  have 
elapsed  before  other  events  may  take  place,  these  timeframes  are 
Interspersed  throughout  the  procedures  and  tend  to  become  some¬ 
what  obscured. 

The  timeframes  for  completion  of  different  events 
and/or  generation  of  other  events  should  be  compiled  into  a  table 
similar  to  the  one  In  Figure  1-96  of  Volume  HI  of  this  Report 
and  placed  into  one  place  in  the  IMM  Manual  to  be  used  as  a  ready 
reference.  The  table  should  contain  the  start  and  stop  dates  for 
measurement  of  the  allowed  times. 
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CHAPTER  VI 


RECOMMENDATIONS 


A.  INTRODUCTION 


The  DODSSR  Study 
with  the  systems  for 
trolling  and  managin 
develop  systems  and 
and  efficient  supply 
ments  •  The  original 

:  Extended 


was  assigned  to  ident 
generating,  transmitt 
g  Supply  Support  Reque 
procedures  improvement 
support  of  Department 
problems  reported  inc 

times 


ify  problems  associated 
ing,  processing,  con- 
8 1 8  (SSRs)  in  order  to 
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The  SSR  Policies  and  Procedures  form  the  basis  of  the  func¬ 
tional  requirements  statement  used  by  the  Components  to  design, 
develop  and  implement  their  systems  for  generating,  transmitting, 
processing  and  controlling  SSRs.  The  study  indicated  that  there 
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were  problems  in  all  areas  studied.  Some  of  the  problems  are 
attributable  to  the  system  design  itself.  Others  are  associated 
with  management  or ganl z at iona 1 /f unc t ional  differences,  while  some 
are  caused  by  the  lack  of  clear  policy  statements.  The  SSR  Proce- 
cedures,  however,  are  a  primary  factor  in  many  of  the  problems 
being  experienced.  Although  the  procedures  provide  punched  card 
formats,  they  appear  to  be  oriented  to  a  manual  batch  processing 
user,  or  a  sequential  batch  process  computer  system  with  excessive 
manual  intervention.  The  procedures  need  to  be  restructured  and 
written  to  accommodate  the  requirements  of  the  system  rather  than 
the  system  being  required  to  adapt  to  inadequate  procedures. 

The  objectives  of  the  study  were: 

:  Decrease  transmission  and  processing  time. 

:  Reduce  reject  and  delinquency  rates. 

:  Improve  systems  for  generating,  transmitting,  pro¬ 

cessing,  controlling  and  managing  supply  support  requests. 

It  is  concluded  that  the  objectives  can  be  best  accomplished 
through  a  combination  of  short-term  and  long-range  improvements 
to  the  system  in  conjunction  with  a  management  and  policy  review 
of  certain  critical  areas.  Accordingly,  the  recommendations  of 
the  Report  are  grouped  into  the  following  categories: 

*  Current  System  Changes 

*  System  Redesign  Requirements 

*  Policy  Review 

*  Management  Review 

The  recommendations  are  based  upon  the  comparative  analysis 
and  conclusions  contained  in  Chapter  V.  The  recommendations  are 
presented  in  summarized  form  for  ease  of  staffing,  coordination, 
approval  and  implementation.  Reference  is  made  to  the  Compara¬ 
tive  Analysis  in  Chapter  V,  Volume  I,  for  rationale  with  support¬ 
ing  detail  contained  in  Volumes  II  and  III  of  the  Report. 

B .  CURRENT  SYSTEM  CHANGES 

The  changes  to  the  current  system  are  recommended  to  correct 
a  small  number  of  conditions  that  are  responsible  for  a  large 
number  of  the  problems  being  experienced  under  the  current  sys¬ 
tem.  These  are  considered  temporary  measures  only,  designed  to 
relieve  the  pressure  until  the  system  can  be  redesigned  to  cor¬ 
rect  the  underlying  causes.  These  changes  were  recommended  to 
the  Components  to  be  Implemented  pending  completion  of  the  DODSSR 
Study  during  a  special  meeting  of  the  Special  Projects  Group  (SPG) 


for  Provisioning  on  3  July  1979.  The  Components  indicated  a 
preference  for  delaying  implementation  of  the  short-range  changes 
until  the  completion  of  the  study.  However,  it  is  understood 
that  the  Defense  Logistics  Agency,  under  its  administrative 
maintenance  responsibilities,  has  commenced  coordination  of  most 
of  the  short-range  recommendations.  The  current  system  recom¬ 
mendations  are  still  considered  valid  due  to  the  time  required 
to  implement  the  system  redesign  recommendations. 

B.l.  It  is  recommended  that  the  Service  Item  Control  Centers 
(SICCs)  be  directed  to  initiate  immediate  action  to  revise  their 
current  systems  to  accomplish  the  following  actions. 

a.  Perform  timely  and  quality  DLSC  screening  within  30 
days  prior  to  the  submission  of  SSRs . 

b.  Predicate  followups  for  advice  on  date  of  submission 
rather  than  on  date  of  request  if  the  date  of  submission  is  sub¬ 
sequent  to  the  date  of  request. 

c.  Perform  a  check  for  duplicate  Provisioning  Control 
Code  (PCC),  Item  Serial  Number  (ISN)  and/or  Date  of  Request  (DOR) 
for  the  same  or  different  items  of  supply  in  the  same  cycle 
prior  to  submission. 

d.  Delay  resubmission  of  a  supply  support  request  for  15 
days  after  receipt  of  a  No  Record  reject  to  preclude  duplicate 
processing  of  the  same  requirement. 

e.  Provide  an  Item  Name  Card  for  each  part  number  SSR. 

f.  Perform  a  more  definitive  item  identification  during 
provisioning  and  SSR  processing  to  provide  more  accurate  item 
identification  information  in  SSRs. 

B.2.  It  is  recommended  that  the  Integrated  Materiel  Managers 
(IMMs)  be  directed  to  initiate  immediate  action  to  revise  their 
current  systems  to  accommodate  the  following  changes: 

a.  Modify  edi t/validation  routines  to  preclude  rejection 
of  supply  support  requests  for  those  data  elements  that  are  not 
critical  to  processing  and  accepting  a  supply  support  request. 

b.  Eliminate  the  distinction  between  Condition  1  and  2 
SSRs,  process  inactive  stock  numbers  for  reactivation  or  rein¬ 
statement  and  obtain  stock  numbers  for  permanent  system  control 
numbers . 


c.  Revise  procedures  to  accommodate  more  than  one  SSR 
for  the  same  Component  during  the  same  Item  Management  Coding 
( IMC )  cycle. 
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d.  Review  use  of  Action  Taken  Code  36  (Other)  to  ensure 
use  of  existing  codes  applicable  to  particular  conditions. 

e.  Obtain  a  new  stock  number  for  reference  number  justi 
fled  items  for  properly  coded  items. 

B.3.  It  is  recommended  that  the  Components  be  directed  to 
revise  their  current  systems  to  Include  the  following  actions. 

a.  Ensure  that  SSR  transactions  and  internal  inquiry 
transactions  are  processed  through  automated  SSR  applications  on 
a  daily  basis. 

b.  Ensure  that  all  SSR  transactions  (provisioning,  non¬ 
provisioning,  changes,  advice,  offer  reply,  followup,  followup 
response)  are  input  to  automated  SSR  applications  by  SICCs  for 
validation  and  preposting  to  the  SSR  suspense  file  before  submis 
sion  and  by  IMMs  for  validation  and  posting  to  the  SSR  suspense 
file  immediately  upon  receipt. 

B.4.  It  is  recommended  that  the  Defense  Logistics  Agency  be 
directed  to  publish  an  Interim  Change  to  the  IMM  Manual  to  issue 
the  following  revisions. 

a.  Revise  the  Action  Taken  Codes  (ATCs)  in  Appendix  E 
of  the  IMM  Manual  to  permit  the  results  of  provisioning  screen¬ 
ing  and  Item  Entry  Control  (IEC)  to  be  used  to  accept  rather 
than  reject  support  for  items  under  the  following  conditions. 

(1)  Support  actual  and  exact  matches  to  stock  num¬ 
bered  items . 

(2)  Support  replaced  NSN/PSCN  items  for  canceled 

Items . 

(3)  Support  standard  NSNs  in  place  of  nonstandard 

Items . 

b.  Revise  the  Action  Taken  Codes  and  associated  proce¬ 
dures  to  require  the  Integrated  Materiel  Manager  to  perform  cata 
log  actions  for  decentralized  items  as  well  as  all  other  items 
for  which  supply  support  is  accepted. 

c.  Revise  the  IMM  Manual  and  Defense  Integrated  Data 
System  Procedures  (DIDS)  to  change  the  definition  of  Acquisition 
Advice  Code  (AAC)  Z  to  apply  only  to  numeric  stockage  objective 
(NSO)  items  and  to  establish  a  separate  new  code  to  apply  to 
insurance  items. 


d.  Revise  the  SSR  Procedures,  data  elements,  codes  and 
formats  to  delete  Quantity  per  End  Item  and  replace  It  with  the 
System  Designator  Code  and  Military  Standard  1552  essentiality 
codes  to  provide  a  convention  for  conveying  and  associating  item 
and  equipment  essentiality  information  for  use  in  method  and 
level  of  support  determinations. 

e.  Revise  SSR  policy  and  procedures  to  require  the  use 
of  AUTODIN  for  all  supply  support  request  transactions  with  asso¬ 
ciated  technical  data  marked  with  SSR  control  data  mailed  via 
priority  mail  to  the  IMM  immediately  after  Source,  Maintenance 
and  Recoverability  (SM&R)  and  Item  Management  Coding  have  been 
accomplished,  and  SSR  candidates  have  been  identified. 

C .  SYSTEM  REDESIGN  REQUIREMENTS 


While  the  current  system  changes  will  correct  some  of  the 
more  immediate  problems  in  SSR  processing,  a  complete  redesign 
of  the  SSR  Procedures  and  Systems  is  required  to  provide  for 
long  term  stability,  effectiveness  and  efficiency  in  the  supply 
support  request  system.  However,  the  recommended  management  and 
policy  improvements  must  also  be  accomplished  to  permit  a  truly 
effective  system  redesign. 

C.l.  It  is  recommended  that  the  Defense  Logistics  Agency  be 
designated  Systems  Administrator  of  the  IMM  Program,  and  directed 
to  reorganize  and  merge  the  Defense  Integrated  Materiel  Manage¬ 
ment  Manual  for  Consumable  Items,  Volumes  I  and  II,  into  one 
volume  as  indicated  below. 

a.  The  Introductory,  Item  Assignments,  Logistic  Reas¬ 
signment  and  Financial  Operations  Chapters  for  WIMM  items  in 
Volume  II  should  be  merged  with  like  chapters  in  Volume  I  to 
accompany  the  joint  CIMM/WIMM  SSR  procedures  already  contained 
in  Volume  I  in  order  to  eliminate  redundancy,  update  obsolete 
material  in  Volume  II  and  to  provide  a  true  procedures  manual 
that  implements  the  policy,  objectives  and  intent  of  the  DoD 
directive  for  integrated  materiel  management.  Sections  of 
Volume  II  that  are  redundant  with  procedures  contained  in  other 
military  systems  procedures  manuals  should  be  eliminated. 

b.  Chapter  I,  Introduction,  should  be  revised  to  provide 
integrated  materiel  management  policy  applicable  to  both  the  IMC 
and  SSR  programs  for  all  IMM  items  and  the  policies,  responsibil¬ 
ities,  procedures  and  appendices  should  be  portrayed  in  a  stan¬ 
dard  manner  for  all  procedures  chapters. 

C.2.  It  is  recommended  that  the  Defense  Logistics  Agency  be 
directed  as  Systems  Administrator  of  the  IMM  Program,  to  estab¬ 
lish  a  formal  system  for  administration  and  maintenance  of  the 
IMM  Manual  to  provide  the  following  features. 
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a.  Spell  out  the  responsibility  for  administration  and 
maintenance  of  both  the  IMC  and  SSR  programs. 

b.  Establish  a  formal  change,  proposal,  review,  coor¬ 
dination  and  control  process  with  a  standard  numbering  system 
for  formal,  interim  and  proposed  changes. 

c.  Publish  advance  notice  of  changes  to  permit  systems 
design  and  development  to  be  accomplished  by  a  specific  coor¬ 
dinated  implementation  date. 

C.3.  It  is  recommended  that  a  task  be  assigned  to  the  Defense 
Logistics  Analysis  Office  to  revise  the  SSR  Procedures  in  accor¬ 
dance  with  the  following  guidelines. 

a.  Revise  the  general  organization  of  the  SSR  Procedures 
as  follows: 


(1)  Policy  applicable  to  SSRs  should  be  separated 
from  procedures  and  placed  in  the  first  part  of  the  SSR  Chapter. 

(2)  The  policy  clarifications  recommended  by  this 
Study  Report  should  be  included  after  approval  by  OASD  and  the 
applicable  DoD  directives  have  been  revised. 

(3)  The  procedures  should  be  removed  from  Appendix 
E  and  placed  in  the  main  body  of  the  SSR  Chapter  and  merged  with 
the  procedures  contained  there.  The  appendices  should  be  limited 
to  transaction  entry  instructions,  data  elements,  codes,  tables, 
formats  and  exhibits. 

b.  The  definition,  purpose,  and  applicability  sections 
should  be  revised  in  accordance  with  the  policy  recommendations 
of  the  Study  Report  after  approval  by  OASD. 

c.  The  detailed  procedures  section  for  SSRs  should 
clearly  outline  the  responsibilities,  functions  and  tasks  of  SSR 
submitters  (SICCs)  and  receivers  (IMMs)  associated  with  the  major 
events  involved  in  the  generation,  transmission,  processing  and 
control  of  supply  support  requests. 

d.  Standard  validation  procedures,  criteria  and  error 
codes  for  internal  and  external  use  by  both  SICCs  and  IMMs 
including  the  provision  for  accommodating  multiple  errors  in  the 
same  transactions  should  be  published  as  a  part  of  the  SSR  Proce¬ 
dures  . 


e.  The  transaction  identification  system  using  document 
identifier  codes  (DICs)  and  action  taken  codes  (ATCs)  should  be 
completely  revised  to  better  relate  transactions  to  event  types 
and  eliminate  the  package  concept  for  SSR  processing. 
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(1)  The  document  Identifier  codes  for  request  trans 
actions  should  be  revised  to  eliminate  the  CIMM/WIMM  designation 
and  provide  for  requests  for  IMM  items. 

(2)  The  Condition  1,  2,  and  3  distinction  should  be 
abolished  and  requests  should  be  identified  and  processed  as  re¬ 
quests  for  NSN,  PSCN  and  Part  Number  items;  PSCN  items  should  be 
processed  immediately  for  NSNs  and  nonactive  NSNs  processed  for 
reactivation  or  reinstatement. 

(3)  The  distinction  between  provisioning  and  non¬ 
provisioning  items  should  be  eliminated  and  these  items  should 
be  given  the  same  processing  treatment. 

(4)  The  document  Identifier  codes  and  action  taken 
codes  for  advice  transactions  should  be  revised  to  designate  the 
different  types  of  advice  transactions  as  separate  identifiable 
events . 

(5)  The  validation  reject  codes  (ATCs)  should  be 
abolished  entirely  and  a  convention  established  to  identify  up 
to  five  data  element  errors  using  a  data  element  identification 
technique . 

(6)  The  action  taken  codes  for  nonreject  advice 
transactions  should  be  revised  to  provide  for  mnemonic  codes 
that  are  grouped  together  by  transaction  category  so  that  all 
codes  in  a  group  apply  to  the  same  type  of  transaction  such  as 
accept,  offer  or  reply  transaction. 

(7)  The  number  of  transaction  types  and  codes 
should  be  kept  to  a  minimum  and  conditions  with  no  or  minimal 
occurrence  should  be  eliminated. 

f.  Those  data  elements  required  for  each  of  the  SSR 
transaction  types  should  be  retained;  those  not  being  used  or 
not  really  required  should  be  deleted;  those  that  have  a  mar¬ 
ginal  utility  should  be  considered  for  elimination. 

g.  The  SSR  formats  should  be  revised  to  suit  the  new 
transaction  types  after  deletion  of  unrequlred  data  elements, 
and  elimination  of  unnecessary  formats. 

(1)  The  program  data  format  should  be  eliminated 
and  the  retained  data  elements  from  that  format  should  be  merged 
with  the  line  item  request  cards  to  permit  processing  on  a  trans 
action  vice  package  basis. 

(2)  The  catalog  card  formats  should  be  eliminated 
and  retained  data  elements  merged  with  the  line  item  request 
cards  to  minimize  the  number  of  cards  required. 
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h.  A  standard  control  number  should  be  developed  to 
prevent  duplicate  transactions  and  to  facilitate  a  common  or 
universal  communications  and  control  technique. 

(1)  The  control  number  should  be  called  a  document 
number  and  should  consist  of  the  control  elements  such  as  the 
activity  code,  provisioning  control  code,  serial  number  and 
applicable  date. 

(2)  The  document  number  should  designate  the  overall 
control  field  with  subfields  for  the  individual  control  elements 
grouped  together  in  a  logical  order  to  facilitate  a  common  or 
universal  technique  for  accessing,  storing,  retrieving,  sequenc¬ 
ing,  processing,  controlling  and  communication  of  SSR  transac¬ 
tions  within,  between  and  among  systems  and  activities. 

(3)  The  provisioning  line  item  sequence  number 
should  be  used  as  the  serial  number  to  provide  an  audit  trail 

for  tracing  supply  support  request  history  and  to  provide  a  link¬ 
age  between  supply  support  request,  provisioning,  and  technical 
subsystems  for  clarification  of  SSR  rejections  and  to  relate  SSR 
status  with  overall  provisioning  support  status. 

(4)  The  same  PCC  and  PLISN  should  be  assigned  to 
only  one  item  of  supply  by  the  same  SICC  for  the  life  of  the  PCC 
to  preclude  duplicates,  permit  rollup  of  requirements  for  the 
same  item  for  the  same  equipment  and  for  communication  and  file 
control  within,  between  and  among  systems  and  activities. 

i.  A  suspense /hi s tor y  file  should  be  maintained  by  both 
SICCs  and  IMMs  for  all  transactions  for  the  same  document  number 
for  a  period  of  two  years  from  the  completion  of  the  last  action 
on  a  provisioning  project  (PCC). 

(1)  The  date  of  request  should  be  used  for  control 
and  audit  trail  purposes  to  relate  all  subsequent  change  and 
advice  transactions  to  the  initial,  request  for  the  same  item  of 
supply  for  the  same  provisioning  project. 

(2)  A  transaction  date  should  be  placed  in  each 
transaction  which  should  be  used  for  audit  trail  purposes  as 
well  as  the  basic  starting  point  for  measuring  times  for  indi¬ 
vidual  transactions  and  total  supply  support  request  life  cycle 
time.  The  date  of  transaction  should  be  the  date  the  transac¬ 
tion  was  created  and  forwarded  to  AUTODIN  for  transmission. 

j.  The  timeframes  for  completion  of  different  events 
and/or  generation  of  other  events  should  be  compiled  into  a 
table  and  put  into  one  place  in  the  XMM  Manual  to  be  used  as  a 
ready  reference.  The  table  should  contain  start  and  stop  dates 
for  measurement  of  allowed  times. 
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C.4.  It  is  recommended  that  the  Military  Services  and  Defense 
Agencies  be  directed  to  include  the  following  systems  design 
concepts  during  the  system  redesign  required  by  the  revised  SSR 
procedures  . 

a.  The  system  redesign  should  provide  the  following 
processing  concepts. 

(1)  SICCs  ensure  that  all  data  elements  input  to 
the  SSR  process  regardless  of  origination  have  been  properly 
validated  for  format  and  content. 

(2)  Automate  SSR  processing  to  the  fullest  extent 
and  particularly  in  the  major  “vents  of  validation,  catalog  data 
screening,  file  maintenance,  SSR  transaction  generation,  and 
catalog  actions. 

(3)  Input  all  types  of  SSR  transactions  to  the 
automated  SSR  application  for  processing  and  preposting  to  the 
SSR  suspense/history  file  prior  to  submission  by  SICCs  and  for 
automated  processing  immediately  upon  receipt  by  IMMs. 

(4)  Process  all  SSR  transactions  and  other  inputs 
to  automated  SSR  applications  on  a  daily  basis. 

(5)  Whenever  possible,  group  program  modules  which 
logically  follow  one  another  in  processing  into  job  streams. 

b.  The  system  redesign  should  provide  the  following 
file  maintenance  concept. 

(1)  Adopt  the  use  of  skeleton  file  maintenance 
transactions  when  manual  action  is  required  to  provide  a  response 
to  the  internal  system  and  to  generate  the  appropriate  SSR  trans¬ 
action  for  external  transmission. 

(2)  Provide  for  local  inquiries  to  the  automated 
SSR  su s pens e /h i s t o r y  file  on  an  item,  PCC  and  weapons  system/end 
item  basis  which  result  in  a  complete  audit  trail  of  actions 
accomplished  on  an  item  basis  and  provide  for  availability  of 
the  results  to  the  functional  user  within  24  hours  of  submittal. 

c.  The  system  redesign  should  provide  the  following 
control  concepts. 

(1)  Ensure  all  Component  activities  use  the  same 
data  elements  for  control  and  sequencing. 

(2)  Ensure  all  Component  activities  process  SSR 
transactions  in  the  same  sequence. 
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(3)  Provide  for  both  external  and  Internal  functional 
followups  when  processing  actions  are  overdue,  when  a  followup 
Is  received  from  an  external  source  and  when  manual  processing 
Is  required  on  an  exception  basis. 

d.  The  system  redesign  should  provide  the  following  SSR 
suspense/history  file  concepts. 

(1)  Ensure  that  a  single  automated  file  Is  adopted 
as  the  su s pen se /hi s t o r y  file. 

(2)  This  single  automated  file  should  be  sequenced 
the  same  as  the  processing  sequence  and  the  same  by  all  Component 
activities. 

(3)  Eliminate  manual  files  which  contain  information 
which  duplicates  that  resident  in  the  automated  SSR  suspense/ 
history  file. 

D.  POLICY  REVIEW 


During  the  course  of  the  study  a  number  of  problems  were 
noticed  that  required  the  establishment  or  clarification  of 
policy.  In  some  circumstances,  the  problem  area  was  outside  the 
scope  of  the  DODSSR  Study,  so  research  was  limited  to  learning 
enough  about  the  problem  to  permit  a  sufficient  identification 
and  description  of  the  problem  to  recommend  policy  review.  In 
other  cases,  the  area  was  sufficiently  related  to  the  areas  under 
study  that  the  study  group  not  only  identified  and  described  the 
problem,  but  was  able  to  recommend  a  policy  definition,  clarifi¬ 
cation  or  recommendation. 

D.l.  It  is  recommended  that  the  OASD(MRA&L)  clarify  the 
definition,  purpose,  intent,  usage  and  applicability  of  supply 
support  requests  by  adopting  the  following  provisions. 

a.  Redefine  the  definition  of  supply  support  request  as 
"A  request  submitted  by  a  SICC  to  an  IMM  to  obtain  integrated 
materiel  management  support  for  new  or  existing  consumable  items 
of  supply." 

b.  Retain  the  current  definition  of  Integrated  Materiel 
Management  as  defined  in  the  DoD  directive  on  Integrated  Materiel 
Management  as  "The  exercise  of  total  Department  of  Defense  or 
Federal  Government  management  responsibility  for  a  Federal  Supply 
G r oup / Fe d e r a  1  Supply  Class  (FSG/FSC),  commodity  or  Item  by  a 
single  agency"  and  use  in  conjunction  with  the  proposed  defini¬ 
tion  of  a  supply  support  request. 

c.  Describe  the  purpose  of  a  supply  support  request  as 

a  request  for  integrated  materiel  management  support  from  an  IMM 
including  the  accomplishment  of  the  following  actions. 


(1)  Item  Management  Coding.  The  SSR  acts  as  an  IMC 
card  when  the  submitting  Component  has  not  previously  coded  the 
item  for  integrated  materiel  management.  The  IMM  is  charged 
with  the  responsibility  of  acting  as  the  Item  Management  Classi¬ 
fication  Agent  and  providing  cataloging  and  supply  support  for 
items  under  the  cognizance  of  the  IMM. 

(2)  Registration  of  User  Interest.  The  SSR  is  used 
to  request  the  addition  of  an  activity  as  a  user  of  an  item  when 
that  activity  has  not  been  previously  recorded  in  the  records  of 
the  IMM  and  DLSC,  and  for  which  support  has  not  been  previously 
provided . 

(3)  Request  for  Supply  Support.  The  requesting 
activity  provides  a  forecast  of  retail  and  replenishment  quan¬ 
tities  to  support  its  requirements  for  the  support  item  being 
requested  to  the  IMM  to  determine  the  method  and  level  of  sup¬ 
port  to  be  provided.  Method  of  support  includes  the  method  of 
management  by  the  IMM  such  as  centrally  stocked,  or  centrally 
procured  but  not  stocked;  and  level  of  support  includes  the 
quantity  of  materiel  to  be  procured  and/or  stocked  to  support 
the  supply  support  request. 

(4)  Cataloging  Support.  The  SSR  provides  management 
and  technical  data  to  be  used  by  the  IMM  to  perform  item  identi¬ 
fication,  item  entry  control,  stock  number  assignment,  and  cata¬ 
log  update  and  publication. 

d.  Designate  the  supply  support  request  as  the  vehicle 
to  be  used  as  the  method  of  requesting  supply  support  for  con¬ 
sumable  items  whenever  there  is  any  predictable  requirement.  If 
the  expected  demand  is  sporadic  in  nature  or  there  is  no  pre¬ 
dicted  demand,  the  IMC  transaction  may  be  used  for  existing  active 
NSN  items  if  the  SICC  desires  only  to  accomplish  the  cataloging 
actions  of  recording  the  IMC  and  the  user  Interest  of  the  SICC 
Component . 

e.  Make  the  Supply  Support  Request  Procedures  mandatory 
for  all  DoD  and  civil  agenciee  in  requesting  supply  support  for 
consumable  items  with  no  other  procedures  permitted. 

D.2.  It  is  recommended  that  OASD(MRA&L)  review  and  clarify 
the  policies,  procedures  and  criteria  contained  in  DoD  direc¬ 
tives  for  the  generation  of  SSRs  for  the  following  conditions. 

a.  Initial  requests  for  new  and  existing  items. 

b.  Subsequent  submission  of  SSRs  as  initial  or  change 
transactions  to  cover  the  following  circumstances. 
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(1)  Equipment  design  changes. 


(2)  Follow-on  provisioning  of  the  same  equipment 
from  the  same  contractor  under  a  different  contract. 

(3)  Re provis ionlng  of  the  same  equipment  from  a  dif¬ 
ferent  contractor  under  a  different  contract. 

(4)  Phased  provisioning  of  the  same  equipment  from 
the  same  contractor  under  a  formal  program. 

(5)  Requirements  for  the  same  equipment  from  the 
same  contractor  under  the  same  contract  with  equipment  deliveries 
spread  across  multiple  years. 

c.  Nonprovisioning  requirements. 

D.3.  It  is  recommended  that  OASD(MRA&L)  clarify  the  role  of 
the  SICC  and  IMM  in  determining  the  method  of  support  and  level 
of  support  in  terms  of  the  following  issues. 

a.  Should  the  SICC  include  a  method  of  support  in  the 
SSR  using  the  Acquisition  Advice  Code  or  some  other  code,  and 
does  this  constitute  a  recommendation  or  a  mandatory  requirement 
to  the  IMM? 


b.  Should  the  SICC  include  an  identification  of  insur¬ 
ance  or  numeric  stockage  items  in  the  SSR  and  does  this  consti¬ 
tute  a  recommendation  or  a  mandatory  requirement  to  the  IMM? 

c.  Does  the  SICC  or  IMM  have  the  responsibility  of  iden¬ 
tifying  item  essentiality,  should  it  be  related  to  equipment 
essentiality  and  how  should  essentiality  be  applied  in  making 
method  of  support/level  of  support  determinations? 

d.  What  quantity  should  be  entered  into  the  replenish¬ 
ment  quantity  field,  how  should  it  be  used  and  who  should  fund 
the  requirement? 

e.  What  quantity  should  be  entered  into  the  retail  quan¬ 
tity  field,  how  should  it  be  used  and  who  should  fund  the  re¬ 
quirement? 

D.4.  It  is  recommended  that  OASD(MRA&L)  establish  a  policy 
indicating  the  responsibilities  of  the  SICC  and  the  IMM  on  the 
rollup  and  accumulation  of  quantities  for  supply  support  requests 
for  the  same  item  in  the  same  equipment,  system,  or  PCC  for  the 
same  activity  and  for  different  activities. 
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D.5.  It 
review  for 
nical  data 
lished  for 
categories 


is  recommended  that  OASD(MRAfitL)  initiate  a  policy 
technical  data;  the  definition  and  purpose  of  tech- 
should  be  reviewed  and  requirements  should  be  estab- 
its  acquisition,  use  and  retention  for  the  following 
of  usage. 


a.  Selection  of  maintenance  significant  items. 


b.  Item  entry  control. 

c.  Catalog  identification. 


d.  Purchase  description. 

D.6.  It  is  recommended  that  OASD(MRA&L)  define  the  supply 
support  request  cycle  including  start,  completion  and  time  of 
transfer  and  acceptance  of  supply  support  by  the  IMM,  by  adopt¬ 
ing  the  following  proposal. 


The  supply  support  request  cycle  commences  after 
maintenance  significant  items  are  selected  and 
coded  for  integrated  materiel  management  and  it 
is  complete  after  final  accept  advice  including 
an  NSN  for  part  numbered  items  is  received,  and 
support  responsibilities  are  transferred  to  and 
assumed  by  the  IMM  at  that  time.  If  a  stock 
number  is  not  received  for  a  part  numbered  item 
within  the  allowed  time,  the  SICC  may  followup 
if  an  initial  accept  has  been  received  and  may 
submit  part  numbered  requisitions  in  order  to 
receive  materiel  by  the  operational  need  date  if 
no  response  to  the  followup  is  received  in  15 
days  or  if  the  response  does  not  contain  a  stock 
number . 


D.7.  It  Is  recommended  that  OASD(MRA&L)  establish  as  a  matter 
of  policy  that  all  supply  support  requests  should  be  submitted 
via  AUTODIN.  Technical  data  for  part  numbered  items  should  be 
marked  with  control  data  and  sent  by  priority  mail  as  soon  as 
SSR  candidates  are  selected. 


E.  MANAGEMENT  REVIEW 


The  supply  support  request  process  is  only  as  good  as  the 
management  organizations,  systems  and  procedures  that  are  devel¬ 
oped  to  request  and  provide  supply  support.  Although  this  report 
recommends  changes  to  improve  the  supply  support  request  pro¬ 
cessing  system  itself,  it  is  felt  that  a  review  and  improvement 
is  needed  for  management  processes  that  precede  and  are  Involved 
in  the  design  of  systems,  and  the  operational  systems  that  acquire 
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d  provide  the  data  that  identify  items  of  supply  and  is 
tered  into  supply  support  requests  and  used  by  integrated 
teriel  managers  to  make  supply  support  decisions  and  provide 
pply  support. 


E.l.  It  is  recommended  that  the 
encies  be  directed  to  review  the 
signments  at  their  headquarters, 
tivities  in  order  to  ensure  the 
lated  to  the  design,  development 
ve  and  efficient  supply  support 

E.2.  It  is  recommended  that  the 
encies  be  directed  to  review  the 
erations  to  ensure  that  data  req 
ecified  in  the  contract  data  req 
g  documentation  is  validated  and 
ta  is  correctly  entered  prior  to 
cumentation  and  preparing  and  su 
ests  . 

E.3.  It  is  recommended  that  the 
encies  be  directed  to  review  thei 
g  processes  to  ensure  timely  and 
g  of  items  to  ensure  proper  ident 
items  prior  to  preparation  and  s 
quests. 


Military  Services  and  Defense 
organizational /functional 
systems  design  and  operating 
proper  placement  of  functions 
and  implementation  of  effec- 
request  processing  systems. 

Military  Services  and  Defense 
ir  provisioning  processing 
uired  for  entry  into  SSRs  is 
uirements  and  that  provision- 
verified  to  ensure  that  the 
accepting  the  provisioning 
bmitting  supply  support  re- 

Military  Services  and  Defense 
r  automated  and  manual  screen 
quality  local  and  DLSC  screen 
ification  and  classification 
ubmis8lon  of  supply  support 


E.4.  It  is  recommended  that  the  Military  Services  and  Defense 
Agencies  be  directed  to  review  their  Provisioning  Performance 
Schedules  to  ensure  identification  of  IMM  items  and  preparation 
and  submission  of  SSRs  sufficiently  in  advance  of  the  production 
leadtime  and  the  date  repair  parts  are  required  in  order  to 
allow  enough  time  for  the  accomplishment  of  IMM  actions. 


E.5.  It  is  recommended  that  the  Defense  Logistics  Agency,  as 
Systems  Administrator  of  the  IMM  Program,  be  directed  to  estab¬ 
lish  a  performance  evaluation  system  in  conjunction  with  the 
Components  including  performance  elements  and  measurement  cri¬ 
teria,  standards,  goals,  performance  objectives  and  management 
reports  required  to  measure  the  effectiveness  and  efficiency  of 
the  SSR  System  in  accordance  with  the  following  guidelines. 

a.  The  current  timeframes  in  the  IMM  Manual  should  be 
revised  to  provide  for  more  realistic  times  based  upon  the  use 
of  AUTODIN,  elimination  of  the  package  concept  for  processing 
use  of  automated  processing,  use  of  direct  communication  from 
data  processing  to  AUTODIN  processing  and  restricting  manual 
processing  to  a  minimum. 

b.  Allowed  times  should  be  provided  for  the  following 
activities/events: 
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(1)  AUT001N  Transmission 

(2)  Initial  Advice 

(3)  Final/NSN  Advice 

(4)  Offers 

(5)  Replies 

(6)  Followups 

(7)  Responses 

(8)  Resubmission  of  Rejects 

(9)  Request  Cancellation 

(10)  Technical  Data  Submission 

(11)  NSN  Assignment 

(12)  Provisioning  Screening 

(13)  SSR  Generation 

c.  Goals  and  performance  objectives  should  be  estab¬ 
lished  for  the  completion  of  critical  events,  to  measure  accept/ 
reject  rates  and  the  submission  of  technical  data. 

d.  The  performance  measurement  system  should  include 
measurement  criteria  and  management  reports  to  measure  the  ef¬ 
fectiveness  and  efficiency  of  the  SSR  system  including  the 
following  provisions. 

(1)  Reject  rates  should  be  measured  by  reject  sub¬ 
category  and  total  for  all  rejects  by  SICC  and  IMM.  The  report 
should  be  accumulated  by  month  or  quarter  and  the  rates  projected 
to  show  trends. 

(2)  Reject  rates  should  be  developed  for  individual 
reject  code  and  ranked  in  order  of  frequency  and  reviewed  to 
determine  whether  the  causes  of  rejects  are  attributable  to 
activities,  systems  or  procedures  problems. 

(3)  A  technical  data  report  should  show  the  in¬ 
stances  where  technical  data  was  required,  available,  submitted 
and  received.  The  report  should  show  activity  and  system  totals. 

(4)  Statistics  should  be  generated  on  the  rates  of 
followups  and  responses  by  activity  and  system  total. 
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(5)  Statistics  should  be  generated  on  the  reject/ 
resubmission  rates  by  activity  and  system  total. 

(6)  Processing  time  statistics  should  be  produced 
to  measure  the  time  to  accomplish  events  in  accordance  with  the 
allowed  processing  times. 

E.6.  It  is  recommended  that  a  comprehensive  study  be  initiated 
to  determine  the  feasibility  of  scanning  technical  data  at  any 
given  geographic  location,  converting  the  graphic  data  to  an 
electrical  or  electronic  signal  and  transmitting  the  signal  to 
another  geographic  location  to  be  converted  to  an  image  or  fac¬ 
simile  of  the  input  document  of  sufficient  quality  to  be  used 
for  technical  operations  functions  and  retention  in  the  tech¬ 
nical  data  library  repository. 
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OFFICE  OF  THE  ASSISTANT  SECRETARY  OF  DEFENSE 


WASHINGTON.  D  C  20301 


Aug  17  1977 


MEMORANDUM  FOR  THE  ASSISTANT  SECRETARY  OF  THE  ARMY  (IL&FM) 
ASSISTANT  SECRETARY  OF  THE  NAVY  (MRA&L) 
ASSISTANT  SECRETARY  OF  THE  AIR  FORCE  (RD&L) 
DIRECTOR,  DEFENSE  LOGISTICS  AGENCY 


SUBJECT:  Establishment  of  Supply  Support  Request  (SSR)  Study 


Standard  procedures  for  obtaining  supply  support  for  end  items  of 
materiel  from  Integrated  Materiel  Managers  (IMMs)  are  scheduled  to  be 
published  as  Chapter  4  of  Volume  I  of  the  Defense  Integrated  Materiel 
Management  Manual  for  Consumable  Items  effective  1  April  1978.  These 
procedures  have  been  coordinated  and  approved  by  the  Military  Services 
and  Defense  Agencies. 

Subsequent  to  coordination  of  the  new  procedures,  potential  problem 
areas  in  the  processing  of  Supply  Support  Requests  (SSRs),  which  could 
have  an  adverse  effect  upon  supply  support  of  new  systems,  have  surfaced 
during  meetings  of  the  DoD  Special  Projects  Group  (SPG)  for  Provisioning. 
Examples  of  problems  identified  include  extended  transmission  times,  a 
high  rate  of  rejects  and  the  lack  of  a  management  control  system  to 
monitor  and  control  the  overall  SSR  process .  These  problems  should  be 
reviewed  to  identify  and  determine  any  immediate  corrective  actions  that 
can  be  initiated  before  implementation  of  the  draft  procedures.  In 
addition,  an  overall  review  vi  the  SSR  system  is  required  to  identify 
other  recommended  changes  which  would  improve  its  overall  effectiveness. 

The  Director,  Defense  Logistics  Agency  is  requested,  therefore,  to  task 
the  Defense  Logistics  Analysis  Office  (DLAO)  to  conduct  a  review  and 
analysis  of  current  and  proposed  systems  for  the  implementation  of  the 
draft  SSR  procedures.  This  study  should  identify  operational  problems 
requiring  changes  to  SSR  procedures  prior  to  the  scheduled  implementation 
date  and  develop  system  improvements  to  promote  effective  and  efficient 
supply  support. 

Your  cooperation  and  your  support  of  the  DLAO  study  effort  are  requested 
in  order  to  achieve  the  objectives  of  the  study  as  outlined  in  the 
enclosed  study  requirement. 

Enclosure 
As  Stated 


/a/  Paul  H.  Riley 
/t/  PAUL  H.  RILEY 

Deputy  Assistant  Secretary  of  Defense 
(Supply,  Maintenance  &  Services) 
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I .  TITLE 

Supply  Support  Request  (SSR)  Systems  and  Procedures 

II.  STUDY  SPONSOR 

The  Assistant  Secretary  of  Defense,  Manpower,  Reserve 
Affairs  and  Logistics  -  ASD(MRA&L) 

III.  STUDY  AGENCY 

Defense  Logistics  Agency,  Defense  Logistics  Analysis  Office 

IV.  AUTHORITY 

This  study  is  assigned  in  accordance  with  Reference  A  below. 

V .  REFERENCES 

A.  DoDD  5010.22,  Subject:  The  Management  and  Conduct  of 
Studies  and  Analyses 

B.  DoDD  4140.40,  Subject:  Basic  Objectives  and  Policies 
on  Provisioning  of  End  Items  of  Materiel 

C.  DoDI  5100.63,  Subject:  Provisioning  Relationships 
Between  the  Military  Services/Defense  Agencies  and  Commodity- 
Integrated  Materiel  Managers 

D.  DLAR  4140.35,  AR  710-25,  AFR  67-40,  NAVSUPINST  4423. 10B, 
M CO  4423. 9B,  Subject:  Military  Services/Defense  Agencies  - 
Commodity  Integrated  Materiel  Managers  Provisioning  Responsi¬ 
bilities 

E.  DLAR  4130.12,  AR  708-7,  AFR  67-98,  NAVSUPINST  4440. 129C, 
M CO  4410. 12C,  DNAI  4130.4,  NSA/CSS  REG.  60-25,  Subject:  Proce¬ 
dures  for  Use  When  Requesting  Supply  Support  and  Catalog  Action; 
Excluding  the  Provisioning  Process 

F.  DoD  4140. 26M,  Subject:  Defense  Integrated  Materiel 
Management  Manual  for  Consumable  Items,  Volume  I,  Commodity 
Oriented  It  eras 

G.  DoD  4140. 26M,  Subject:  Defense  Integrated  Materiel 
Management  Manual  for  Consumable  Items,  Volume  II,  Weapons 
System  Oriented  Items 
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H.  Item  Logistics  Management  Data  (ILMD)  Study  Report  of 
February  1973 

I.  Draft  DoD  4140. 26M,  Volume  I,  Chapter  4,  Subject:  Supply 
Support  Requests 

VI.  BACKGROUND 


Policy  for  provisioning  end  items  of  materiel  is  contained 
in  Reference  B.  Procedures  for  obtaining  supply  support  from 
Integrated  Materiel  Managers  (IMMs),  implementing  Reference  B 
Policy,  are  contained  in  References  C-G. 

The  ILMD  Study  (Reference  H)  concluded  in  part  that  there 
were  multiple  regulatory  procedures,  formats  and  data  elements 
that  have  an  adverse  effect  upon  Inventory  Control  Point  (ICP) 
supply  support  operations,  and  recommended  that  the  procedures 
contained  in  References  D-G  governing  supply  support  requests 
(SSRs)  be  combined  into  one  DoD  manual.  These  procedures  have 
now  been  revised  and  consolidated  and  are  contained  in  Reference 
I,  which  has  been  coordinated  and  approved  for  implementation  by 
the  Military  Services  and  Defense  Agencies  through  the  DoD 
Special  Projects  Group  (SPG)  for  provisioning  with  a  scheduled 
implementation  date  of  1  April  1978. 

However,  subsequent  to  the  coordination  of  the  new  proce¬ 
dures,  potential  problem  areas  in  the  processing  of  SSRs  which 
could  have  an  adverse  effect  upon  supply  support  of  new  systems 
have  surfaced  during  meetings  of  the  SPG.  Problems  have  been 
Identified  in  the  areas  of  SSR  transmission  times,  excessive 
reject  rates  which  delay  vital  supply  support  and  the  lack  of  an 
effective  management  control  system  to  effectively  monitor  and 
control  the  overall  SSR  process.  These  problems  should  be 
reviewed  to  identify  and  recommend  any  immediate  corrective 
actions  that  can  be  initiated  prior  to  the  implementation  of  the 
draft  procedures.  A  further  review  should  be  made  of  the  entire 
DoD  SSR  system  to  identify  any  long  range  improvements  that  may 
be  necessary. 

VII.  STUDY  DESCRIPTION 

A.  PROBLEM 


SSRs  are  not  being  processed  in  a  timely  manner  which  is 
necessary  to  ensure  effective  and  efficient  supply  support  of 
end  items  of  materiel. 


Appendix  A,  page  3 


233 


B 


PURPOSE 


The  study  Is  being  conducted  to  review  and  analyze  the 
SSR  processing  system.  The  study  will  identify  problems  asso¬ 
ciated  with  the  systems  used  to  generate,  transmit,  process  and 
control  S S Rs  and  recommend  both  short  and  long  range  improve¬ 
ments  to  increase  the  effectiveness  of  the  system. 

C.  OBJECTIVES 


Improvements  sought  are: 

1.  Decrease  in  supply  support  transmission  and  pro¬ 
cessing  t  irae  s . 

2.  Reduction  in  the  SSR  rejection  and  delinquency  rates. 

3.  Improved  SSR  and  interfacing  systems  for  trans¬ 
mitting,  processing  and  controlling  SSRs. 

D.  SCOPE 


The  study  will  review  and  analyze  the  SSR  pipeline  from 
generation  through  completion  of  processing  of  SSRs. 

1 .  Systems  Types 

a.  Generating.  Only  SSRs  and  related  output  from 
provisioning  or  other  generating  systems  will  be  considered. 
Excluded  are  the  decision  processes  for  determining  what  items 
will  require  support  (range  and  depth),  who  will  provide  the 
required  support  and  when  the  required  support  is  to  be  pro¬ 
vided.  Consumable  items  only  will  he  considered. 

b.  Transmittal/Communication  -  mode,  media,  and 

t imi ng . 


c.  Processing  -  receipt,  validation,  acceptance, 
offer  and  rejection. 

d.  Cont  rol  -  history,  advice,  status,  followup 
and  management  control. 

2 .  Systems  Considerations 

Procedures,  inputs,  outputs,  files,  formats,  media, 
content,  data  elements,  codes,  definitions,  timing  and  tech¬ 
niques  related  to  the  sy s t ems / s ub s y s t ems  described  above,  or  to 
interfacing  systems. 
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3 .  Organizat Ions 

All  DoD  and  Federal  Components  Involved  in  the  pro¬ 
cedures  contained  in  Reference  I  or  systems  types  described 
a  hove . 

4 .  Definition 

Supply  Support  Requests  for  the  purpose  of  this 
study  will  Include  all  data/information  required  to  request  and 
obtain  supply  support  for  end  items  of  equipment  whether  through 
provisioning  or  nonprovisioning  processes. 

E .  APPROACH 

The  study  will  consist  of  two  main  phases. 

1 .  Short  Range 

This  phase  will  consist  of  a  review  of  current  and 
proposed  efforts  to  implement  the  procedures  contained  in 
Reference  I.  The  primary  objective  will  be  to  identify  those 
changes  that  must  be  accomplished  to  permit  a  working  implemen¬ 
tation  of  the  draft  procedures  by  the  scheduled  implementation 
date  of  1  April  1978. 

This  Phase  1  will  also  serve  as  the  background 
review  or  foundation  for  the  accomplishment  of  Phase  2. 

2 .  Long  Range 

This  phase  will  be  oriented  towards  generating 
system  improvements  in  the  transmittal,  processing,  and  control 
of  SSRs  in  order  to  achieve  objectives  1  to  3  above  and  to  pro¬ 
mote  effective  and  efficient  supply  support  of  end  items  of 
materiel. 

F .  ASSUMPTION 

There  will  be  a  single  DoD  Manual  with  one  set  of  for¬ 
mats,  document  identifiers,  procedures  and  codes  for  the  inter¬ 
change  and  processing  of  supply  support  data. 

VIII.  RESPONSIBILITIES 

A .  AS  D ( MRA&L ) 

ASD ( UR A&L ) S D  is  the  primary  study  sponsor  and  is  respon¬ 
sible  for: 

Appendix  A,  page  5 

235 


1.  Study  definition  and  scope* 

2.  Establishment  of  objectives. 

3.  Study  assignment  and  tasking. 

A.  Monitoring  study  progress. 

5.  Receipt,  coordination  and  implementation  of  study 

result  s. 

B.  DEFENSE  LOGISTICS  ANALYSIS  OFFICE 


The  D LAO  is  responsible  for  the  conduct  of  the  study 
i nc lu  d l ng : 

1.  Determining,  requesting,  obtaining  or  supplying 
resources  to  perform  the  study. 

2.  Development  and  application  of  study  methodology 
including  identifying,  collecting,  obtaining  or  developing  data/ 
information  and  techniques  to  analyze  systems  and  evaluate 
alternatives  for  accomplishment  of  study  objectives. 

3.  The  study  group  is  authorized  direct  contact  with 
the  military  departments  and  defense  agencies  during  the  con¬ 
duct  of  the  study. 

C.  THE  MILITARY  DEPARTMENTS  AND  THE  DEFENSE  AGENCIES 


The  military  departments  and  the  defense  agencies  are: 

1.  Responsible  for  participating  in  the  study  by  pro¬ 
viding  briefings,  data,  information,  documents  and  arranging  for 
visits  and  representation  as  required  by  the  study  group  for 
completion  of  the  study. 

2.  Responsible  for  designating  a  point  of  contact  to 
facilitate  the  conduct  of  the  study.  The  point  of  contact 
should  he  provided  directly  to  the  study  agency  to  the  attention 
of  the  DLAO  study  team  director  within  two  weeks  after  the 
receipt  of  this  study  requirement.  The  SPG  for  provisioning 
member  should  be  assigned  as  point  of  contact. 

IX.  ADMINISTRATION 

A .  STAFFING 

l .  Study  Manager 

The  OSD  Project  Officer  for  this  study  is  LTC  Larry 
N.  Wellman,  OASD  (  MR  A&L  )  SR. 
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Study  Team  Director 


To  be  designated  by  DLAO. 

3 .  Members 

The  study  group  will  be  composed  of  highly  qualified 
personnel  with  the  skills  as  outlined  below.  DoD  components  may 
be  tasked  individually  to  provide  representation  to  fill  one  or 
more  of  these  staffing  requirements. 


DoD  Component 

Experience 

Number 

DLA 

Computer  Systems  Analyst 

1 

DLAO 

Logistics  Systems  Analyst 

2 

DLA/DLAO 

Economic  Analysis  Analyst 

1 

4 .  Contact 

Points 

Each  of  the  military  departments  and  the  Defense 
Logistics  Agency  will  assign  a  single  point  of  contact  to  coor¬ 
dinate  study  group  requirements  for  briefings,  data.  Informa¬ 
tion,  documents,  visits  and  se rvi c e/a ge ncy  participation  in  the 
study  effort. 

B .  SCHEDULE 

1.  Short  Range  -  31  December  1977 

2.  Long  Range  -  30  September  1978 

C .  DATA  COLLECTION 

The  study  group  is  authorized  to  collect  data/lnforma* 
t ion  as  required  for  the  accomplishment  of  this  project.  Data 
may  be  collected  during  on-site  field  research  or  as  a  part  of  a 
formal  data  collection.  Data  may  be  collected  from  existing 
d  ocume  nta  t  ion  or  files  and  may  be  manually  or  mechanically 
collected.  Each  DoD  Component  will  perform  in  a  timely  manner 
the  ma nual/me chanical  processing  involved  in  a  formal  data 
collection  and  fund  any  costs  involved  in  the  collection  and 
submission  of  required  data. 

D .  OTHER  ADMINISTRATIVE  SUPPORT 

1.  Administrative  support  for  this  study  will  be  pro¬ 
vided  by  the  Director,  Defense  Logistics  Agency  (DLA). 
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2.  Travel  will  be  funded  by  the  parent  DoD  Component 
for  each  me mb e r / r e p r e s e n t a t 1 ve  and  blanket  travel  orders  with 
appropriate  fund  citations  are  requested  for  each  member  to 
facilitate  travel  request  processing  and  payment  by  DLA. 

3.  The  Study  Team  is  authorized  direct  correspondence 
with  DoD  Components,  other  Government  Agencies,  private  industry, 
and  educational  and  industrial  associations  to  arrange  field 
visits,  briefings  and  coordinate  data  requests  and  other  per¬ 
tinent  documents  related  to  the  accomplishment  of  this  study. 
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ACTIVITIES  VISITED  OR  CONSULTED 


LOGISTICS  HEADQUARTERS 
Army 

Deputy  Chief  of  Staff  for  Logistics,  Washington,  D.C. 
U.S.  Army  Development  and  Readiness  Command,  Alexandria, 
Virginia 


Navy 


Naval  Supply  Systems  Command,  Washington,  D.C. 


Air  Force 


Deputy  Chief  of  Staff  for  Logistics  and  Engineering, 
Washington,  D.C. 

Air  Force  Logistics  Command,  Dayton,  Ohio 

Marine  Corps ,  Headquarters,  Washington,  D.C. 

United  States  Coast  Guard,  Headquarters,  Washington,  D.C. 

Defense  Logistics  Agency,  Headquarters,  Alexandria,  Virginia 

General  Services  Administration,  Federal  Supply  Service, 
Washington ,  D.C . 

LOGISTICS  SERVICE 

Army 

Catalog  Data  Activity,  New  Cumberland,  Pennsylvania 
Air  Force 

Cataloging  and  Standardization  Office,  Battle  Creek, 

M i c  hi gan 

Defense  Logistics  Agency 

Defense  Logistics  Services  Center,  Battle  Creek, 

Michigan 
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Army 

Automated  Logistics  Management  Systems  Activity, 
St.  Louis,  Missouri 


Navy 


Fleet  Material  Support  Office,  Mechanicsburg,  Pennsylvania 


Air  Force 


Comptroller,  Headquarters  2852d  Air  Base  Group, 
McClellan  Air  Force  Base,  California 
Comptroller,  Headquarters  284th  Air  Base  Group,  Hill 
Air  Force  Base,  Utah 

Marine  Corps 

Marine  Corps  Support  Base  Atlantic,  Albany,  Georgia 

Defense  Logistics  Agency 

Systems  Automation  Center,  Columbus,  Ohio 

General  Services  Administration,  Federal  Supply  Service, 
Washington,  D.C. 

OPERATING  ( SICC/CIMM/WIMM) 


Army 


U.S.  Array  Tank-Automotive  Materiel  Readiness  Command, 
Warren,  Michigan 

U.S.  Army  Troop  Support  and  Aviation  Materiel  Readiness 
Command,  St.  Louis,  Missour' 


Ships  Parts  Control  Center,  Mechanicsburg,  Pennsylvania 
Air  F  ~rce 

Sact  nto  Air  Logistics  Center,  Sacramento,  California 
Ogden  r..  r  Logistics  Center,  Ogden,  Utah 
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Marine  Corps  Logistics  Support  Base  Atlantic,  Albany, 
Georgia 

Defense  Logistics  Agency 

Defense  Construction  Supply  Center,  Columbus,  Ohio 
Defense  Electronics  Supply  Center,  Dayton,  Ohio 
Defense  General  Supply  Center,  Richmond,  Virginia 

General  Services  Administration,  Federal  Supply  Service, 
Washington,  D.C. 

ADMINISTRATIVE  AND  TECHNICAL  SUPPORT 

Defense  Logistics  Agency  Administrative  Support  Center, 
Alexandria,  Virginia 

Acquisition  Logistics  Division,  Air  Force  Logistics 
Command,  Dayton,  Ohio 

Alden  Electronic  and  Impulse  Recording  Equipment  Company, 
Westborough,  Massachusetts 
Computer  Sciences  Corporation,  Rosslyn,  Virginia 
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DoDI  7935.1,  DoD  Automated  Data  Systems  Documentation  Standards, 
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Functional  Description  for  AFLC  Provisioning  System  DSD  D220, 
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Functional  Description  for  Supply  Support  Request  (SSR)/Advice  - 
Consumable  Items  Systems  (D169),  3  April  1978. 
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HQ  AFLC  SMALC/MMOI  57-44,  26  January  1979,  Processing  Supply 
Support  Requests  (SSRs)  Advice  D169  System. 
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Program  Support  I n t e r e s t / Mas t e r  Data  F 1 1 e /Tec hn 1 ca 1  Reference 
File  Maintenance  Training  Manual,  September  1977. 
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ACRONYMS 


AAC; 

ACF : 

ACN: 

ACT: 

ADP: 

ADS: 

AFLC : 

AICP: 

ALC: 

ALMSA : 

ARCSIP: 


Acquisition  Advice  Code 
Activity  Code  From 
Activity  Control  Number 
Activity  Code  To 
Automatic  Data  Processing 
Automated  Data  System 
Air  Force  Logistics  Command 
Aviation  Inventory  Control  Point 
Air  Logistics  Center 

Automated  Logistics  Management  Systems  Activity 


ARCSIP :  Automated  Requirements  Computation  System  Initial 

Provisioning 

ASD(MR&L) ;  Assistant  Secretary  of  Defense  (Manpower,  Reserve 
Affairs  and  Logistics 
ASO :  Aviation  Supply  Office 

ATC :  Action  Taken  Code 

AUTODIN :  Automatic  Digital  Network 


BDN :  Bulk  Data  Network 


CAMF :  Catalog  Action  Monitor/Master  File 

CASO :  Cataloging  and  Standardization  Office 

CCSOI :  Commodity  Command  Standard  System  Operating  Instruction 

CCSS :  Commodity  Command  Standard  System 

CPA :  Catalog  Data  Activity 

CDPD :  Central  Data  Processing  Division 

CESO :  Civil  Engineer  Support  Office 

CIMM :  Commodity  Integrated  Materiel  Manager 

CMP :  Computer  Management  Division 

COB :  Catalog  Operations  Branch 

CPCI :  Computer  Program  Configuration  Item 

CRF :  Cross  Reference  File 

CSDS :  Clerical  Screening  and  Distribution  Section 

CSLA :  Communications  Security  Logistics  Agency 


DAB :  Data  Automation  Branch 

DAC :  Document  Availability  Code 

DARCOM:  Department  of  Army  Readiness  Command 

DCN :  Design  Change  Notice 

DCS :  Deputy  Chief  of  Staff 
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DCSC:  Defense  Construction  Supply  Center 

DESC :  Defense  Electronics  Supply  Center 

DGSC:  Defense  General  Supply  Center 

PIC :  Document  Identifier  Code 

DIPS:  Defense  Integrated  Data  System 

DIDSTIR:  Defense  Integrated  Data  System  Total  Item  Record 

DLA :  Defense  Logistics  Agency 

DLAO :  Defense  Logistics  Analysis  Office 

DLSC :  Defense  Logistics  Services  Center 

DM:  Directorate  for  Maintenance 

DM B :  Data  Management  Branch 

DM  I S :  Directorate  for  Management  Information  Systems 

DMM :  Directorate  of  Materiel  Management 

DOA :  Date  of  Advice 

DoD:  Department  of  Defense 

DODSSR:  Department  of  Defense  Supply  Support  Request 

DOR :  Date  of  Request 

DPP :  Directorate  for  Procurement  and  Production 

DPS :  Data  Processing  Specification 

DRPR :  Date  Repair  Parts  Required 

DSAC:  Defense  Logistics  Agency  Systems  Automation  Center 

DSB :  Data  Services  Branch 

DSC :  Defense  Supply  Center 

DSCN :  Document  Serial  Control  Number 

DSFA:  Designated  Special  Functions  Activity 

DSO :  Directorate  of  Supply  Operations 

DTDS:  Date  Technical  Data  to  be  Supplied 

DTP :  Directorate  of  Technical  Operations 


EAM :  Electronic  Accounting  Machine 

EGICP :  Electronics/General  Inventory  Control  Point 

E/ I :  End  Item 

E  I  P  :  End  Item  Parameter 

EM RA :  Electronics  Materiel  Readiness  Activity 

ERB :  Engineering  and  Reliability  Branch 


FCS:  Federal  Catalog  System 

FFCG :  Field  Functional  Coordination  Group 

F I I :  Federal  Item  Identification 

F I IG :  Federal  Item  Identification  Guide 

FLDF :  Federal  Logistics  Data  File 

FMSO :  Fleet  Material  Support  Office 

FSC :  Federal  Supply  Class 

FSCM :  Federal  Supply  Code  for  Manufacturers 

FSG :  Federal  Supply  Group 

FSS :  Federal  Supply  System/Service 
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GMPA:  General  Materiel  and  Petroleum  Activity 

GSA:  General  Services  Administration 

GSA-FSS :  General  Services  Administration,  Pederal  Supply  Service 


HME&O :  Hull,  Mechanical  and  Ordnance 


ICP :  Inventory  Control  Point 

ICR :  Item  Control  Recommendation 

IEB :  Item  Entry  Branch 

IEC :  Item  Entry  Control 

II :  Item  Identification 

I IB :  Item  Identification  Branch 

ILMD :  Item  Logistics  Management  Data 

ILSO :  Integrated  Logistics  Support  Office 

IM :  Item  Manager /Management 

IMC ;  Item  Management  Coding 

IMM :  Integrated  Materiel  Manager 

IRPOD :  Individual  Repair  Parts  Ordering  Data 

ISF :  Interface  Suspense  File 

ISN:  Item  Serial  Number 


LDM :  Logistics  Data  Management 

LDMD ;  Logistics  Data  Management  Division 

LI AC :  Line  Item  Advice  Card 

LISSR :  Line  Item  Supply  Support  Request 

LOA .  Level  of  Authority 

LSB ;  Logistics  Support  Base 


MAB :  Management  Analysis  Branch 

MAPL :  Master  Associated  Provisioning  List 

MCASC ;  Marine  Corps  Automated  Services  Center 

MCLSBA:  Marine  Corps  Logistics  Support  Base  Atlantic 

MCN :  Management  Control  Number 

MCRL :  Master  Cross  Reference  List 

MDF :  Master  Data  File 

MIF :  Master  Inventory  File 

MMAC :  Materiel  Management  Aggregation  Code 

MMD :  Materiel  Management  Decision 

MOE :  Major  Organizational  Entity 

MRC :  Materiel  Readiness  Command 

MRMDS :  Master  Reference  and  Management  Data  System 

MSB;  Materiel  Support  Branch 

MUMMS :  Marine  Corps  Unified  Materiel  Management  System 


NAVSUP :  Naval  Supply  Systems  Command 

NI I N :  National  Item  Identification  Number 
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NIMSR 
NSN: 
NSO : 


OPS: 

ONR: 

OOALC 

OPR: 


PCAM : 
PCC : 
PCCN : 
PCO : 
PD: 
PDCN : 
PDR : 
PDSSR 
PICA: 
PIO: 
PLISN 
PLT : 
PMB : 
PMC: 
PMF : 
PMR: 
PPR: 
PRF : 
PSCN: 
PSI: 
PTD : 
PXR : 


REFNO 
RNCC : 
RNFC : 
RiDC: 
RNVC : 


SAMMS 

SCR: 

SPA: 


Nonconsumable  Item  Materiel  Support  Request 
National  Stock  Number 
Numeric  Stockage  Objective 


Office  of  Data  Systems 
Old  NUN  Reference 

Ogden  Air  Logistics  Center 
Office  of  Primary  Interest 


Punched  Card  Accounting  Machine 
Provisioning  Control  Code 
Provisioning  Contract  Control  Number 
Provisioning  Contract  Office 
Provisioning  Division 

Provisioning  Document  Control  Number 
Program  Data  Record 

Program  Data  Supply  Support  Request 
Primary  Inventory  Control  Activity 
Provisioning  Item  Order 

Provisioning  Line  Item  Serial  Number 
Production  Lead  Time 
Program  Management  Branch 
Procurement  Method  Code 
Provisioning  Monitoring  File 
Provisioning  Master  Record 
Planned  Program  Requirements 
Project  Requirements  File 
Permanent  System  Control  Number 
Program  Support  Interest 
Provisioning  Technical  Documentation 
Provisioning  Cross  Reference 


Quality  Assurance  Division 


Reference  Number 
Reference  Number  Category  Code 
Reference  Number  Format  Code 
Reference  Number  Justification  Code 
Reference  Number  Variation  Code 


Standard  Automated  Materiel  Management  System 
Systems  Change  Request 
Systems  Design  Activity 
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SFB :  Stock  Fund  Branch 

SICA;  Secondary  Inventory  Control  Activity 

SICC :  Service  Item  Control  Center 

SICP ;  Ships  Inventory  Control  Point 

SM&R ;  Source,  Maintenance  and  Recoverability 

SMALC :  Sacramento  Air  Logistics  Center 

SMCC :  Special  Materiel  Content  Code 

SMS :  Supply  Management  Suspense 

SPC:  Systems  Policy  and  Concepts 

SPCC ;  Ships  Parts  Control  Center 

SPG :  Special  Projects  Group 

SPR :  Special  Program  Requirement 

SPU ;  Special  Programs  Unit 

SSR:  Supply  Support  Request 


TARCOM ;  Tank-Automotive  Materiel  Readiness  Command 

TCC :  Type  of  Change  Code 

TDJC :  Technical  Data  Justification  Code 

TDMO :  Technical  Data  Management  Office 

TIP ;  Technical  Information  Division 

TIR :  Total  Item  Record 

TOD i  Technical  Operations  Division 

TRF ;  Technical  Reference  File 

TSARCOM :  Troop  Support  and  Aviation  Materiel  Readiness 

Command 

TSD:  Technical  Services  Division 


SP :  Uniform  Automated  Data  Processing  System  for  Stock 

Points 

Afloat :  Uniform  Automated  Data  Processing  System  for 

Ships 

Unit  of  Issue 

Uniform  Inventory  Control  Point 


WIMM;  Weapons  Integrated  Materiel  Manager 
WSC :  Weapon  System  Code 

WSF ;  Weapons  Systems  File 

WSSP:  Weapon  Systems  Support  Program 


UADPS- 

UADPS- 

U/I: 
UICP : 
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